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VOORWOORD 


De complexiteit van informatiesystemen neemt in de praktijk hand over hand toe. De 
behoefte aan formele specificaties van zulke complexe systemen wordt dientengevolge 
steeds groter. Deze behoefte betreft niet alleen de formele specificatie van het zogeheten 
gegevensmodel van een organisatie, maar ook van het zogeheten procesmodel. Het 
gegevensmodel bestaat uit de voor deze organisatie relevante gegevens(structuren) en de 
voor deze gegevens geldende randvoorwaarden (die in dit verband meestal constraints wor- 
den genoemd). Het procesmodel daarentegen bevat de voor de organisatie relevante 
raadpleeg- en wijzigingsoperaties op de gegevens. Deze formele modellen kunnen als 
leidraad dienen voor de implementatie en het gebruik van dergelijke complexe systemen. 
Met de huidige, op de markt beschikbare database-managementsystemen laten zulke wiskun- 
dige modellen zich overigens op steeds directere wijze naar een implementatie vertalen. 
Deze tendens dat de afstand tussen formele specificatie en implementatie steeds kleiner 
wordt, onderstreept eens te meer het groeiende belang van formele specificaties van informa- 
tiesystemen. 


Dit boek laat zien hoe dergelijke (systeemonafhankelijke) formele specificaties er uit kunnen 
zien en ook in complexe situaties praktisch bruikbaar (en in feite zelfs onmisbaar) zijn. 
Tevens wordt duidelijk gemaakt hoe een belangrijk deel van de semantiek van de gegevens 
kan worden weerspiegeld in het formele gegevens- en procesmodel van een organisatie. 
Hieraan ligt het inzicht ten grondslag dat de semantiek van de gegevens bepalend is voor de 
constraints waaraan deze gegevens en de operaties op deze gegevens dienen te voldoen. Hoe 
deze door de semantiek bepaalde constraints als wezenlijk onderdeel in de definitie van het 
wiskundige model van de gegevens en hun operaties zelf kunnen worden opgenomen, is één 
van de hoofdthema’s van dit boek. Omdat het juist de intentie van semantische dababases is 
om zoveel mogelijk van de semantiek van de gegevens in het formele model zelf op te 
nemen, is hiermee tevens de titel van het onderhavige boek verklaard. De hier gegeven aan- 
pak is reeds herhaalde malen in zeer uiteenlopende praktijksituaties toegepast en heeft daar- 
bij zijn bruikbaarheid voor het modelleren van informatiesystemen duidelijk bewezen. 
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Het onderhavige boek is een grondige bewerking en uitbreiding van eerdere aantekeningen 
ten behoeve van een college Database-systemen dat ondergetekende de afgelopen vijf jaar 
heeft gegeven aan de Technische Universiteit Eindhoven. 


Hoofdstuk 0 bevat de definities en elementaire eigenschappen van de algemene wiskundige 
basisbegrippen die in de rest van het boek worden gebruikt. 


In Hoofdstuk 1 worden de drie kernbegrippen tabel, database-toestand en database- 
universum formeel gedefinieerd. Deze begrippen vormen de basis voor de rest van stof. 


Hoofdstuk 2 behandelt diverse centrale onderwerpen uit de theorie van databases: 


— operaties op tabellen (projectie, join, renaming, etcetera), 
—  afhankelijkheden, (minimale) sleutels en normaalvormen, 
— referentiële integriteit en database-functies, en 

— operaties op database-universa. 


Veel nadruk wordt hierbij gelegd op het belangrijke onderscheid tussen incidentele eigen- 
schappen (dat wil zeggen eigenschappen van toestanden) en structurele eigenschappen (dat 
wil zeggen eigenschappen van toestandsruimten). Helaas worden in vele theoretische én 
praktische verhandelingen deze verschillende niveaus niet duidelijk onderscheiden. 


Hoofdstuk 3 is gewijd aan het systematisch construeren van database-universa in de praktijk. 
In dit hoofdstuk wordt een classificatie van (statische) constraints gegeven, geïllustreerd aan 
de hand van diverse praktijkvoorbeelden. Ook komt hier het modelleren van generalisatie en 
specialisatie (alias differentiatie) aan bod. 


Om enig inzicht te geven in de specifieke problemen die kunnen ontstaan bij complexe data- 
bases, bevat Hoofdstuk 4 een omvangrijk voorbeeld van een database-universum. Dit voor- 
beeld is de bekende ziekenhuis-case die intussen zowel nationaal als internationaal wordt 
gebruikt voor de evaluatie van de functionele eigenschappen van diverse toonaangevende 
database-managementsystemen, zie bijvoorbeeld [IDT 88] en [NGI 88]. Vele soorten con- 
straints die men in de praktijk kan tegenkomen, hebben een analogon in dit niet-triviale 
voorbeeld. 


Hoofdstuk 5 geeft een formele behandeling van dynamische constraints, dat wil zeggen eisen 
aan de toegestane toestandsovergangen. Dit hoofdstuk bevat tevens een uitgebreid voorbeeld 
met vele soorten dynamische constraints, gebaseerd op het ziekenhuisvoorbeeld uit 
Hoofdstuk 4. 


Hoofdstuk 6 gaat in op het raadplegen van een database. In dit hoofdstuk worden formele 
definities van de begrippen query en view gegeven. Ook worden deze begrippen 
geïllustreerd aan de hand van diverse voorbeelden. 
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Hoofdstuk 7 bevat een wiskundige behandeling van het onderhoud van een database middels 
elementaire tot zeer complexe (trans)acties. De transacties worden hierbij dan ook niet 
imperatief of operationeel maar declaratief beschreven. Naast het algemene transactiebegrip 
worden ook enige meer specifieke, SQL-achtige klassen van transacties gedefinieerd. 


In Hoofdstuk 8 wordt ingegaan op data dictionaries. Zoals een formele theorie van databases 
nodig is om te abstraheren van specifieke applicaties, zo is een formele theorie van data dic- 
tionaries nodig om te kunnen abstraheren van specifieke data dictionarysystemen. Ondanks 
de snel groeiende belangstelling voor (en mogelijkheden van) de huidige data dictionary- 
systemen schijnt er nog nauwelijks een formele theorie van data dictionaries te bestaan. In 
het laatste hoofdstuk van het boek wordt een begin gemaakt met zo’n formele theorie van 
data dictionaries. In het bijzonder wordt het data-definitiegedeelte van data dictionaries aan 
een nadere (formele) beschouwing onderworpen. Ter illustratie worden enige simpele struc- 
turen voor data dictionaries gedefinieerd en aan de hand van een voorbeeld helemaal "door- 
gerekend". 


Het boek bevat een ruime sortering opgaven. Hierin komen zowel theoretische als praktische 
aspecten aan bod. Voor een goede verwerking van de stof is het ten zeerste aan te bevelen 
(een groot deel van) de opgaven ook daadwerkelijk te maken. 


In het onderhavige boek wordt veel aandacht besteed aan het kunnen vertalen van informele 
omschrijvingen naar formele specificaties, en omgekeerd. Immers, dit is de schakel tussen de 
organisatie- en materie-deskundigen van de te modelleren toepassing enerzijds en de sy- 
steemdeskundigen anderzijds (waarbij het uiteraard niet uitgesloten is dat deze verschillende 
functies in dezelfde persoon verenigd kunnen zijn). 


Langs deze weg wil ik graag alle collega’s en studenten bedanken die de afgelopen jaren 
bewust of onbewust hebben bijgedragen aan de vele ervaringen waarop de inhoud van dit 
boek voor een niet gering deel berust. In het bijzonder wil ik in dit verband Frans Remmen 
noemen. Het evenwicht tussen theorie en praktijk dat ik in mijn werk op het gebied van data- 
bases gevonden hoop te hebben is namelijk voor een groot deel aan hem te danken. 


Mijn werkgever Philips dank ik voor de geboden gelegenheid om ook een deel van het boek 
onder werktijd te kunnen schrijven. 


Frank Pieper en Frans Remmen wil ik zeer nadrukkelijk bedanken voor de grondige manier 
waarop zij als reviewers de tekst hebben doorgenomen, gecontroleerd en becommentarieerd. 
(Dit geldt in het bijzonder voor het nu reeds beruchte Voorbeeld 7.2.) Hun commentaar heeft 
de leesbaarheid van het boek dan ook duidelijk naar een hoger plan getild. 


Suzanne den Ouden wil ik bedanken voor de zeer kundige en keurige wijze waarop zij het 
typewerk heeft verzorgd. Dat er tussen het aanleveren van de eerste bladzijden en de laatste 
bladzijden van het manuscript meer dan een jaar verschil zat heeft haar taak er zeker niet 


gemakkelijker op gemaakt. 


Verder dank ik Jan Willem Nienhuys voor de bereidwilligheid waarmee hij speciaal ten 
behoeve van dit boek diverse troff-macro’s heeft vervaardigd. 


Ten slotte wil ik Audrey de Brock-Blank bedanken voor haar morele steun en voor het vele 
geduld dat zij bij elke verschuiving van de opleveringsdatum van het boek toch telkens weer 


bleek te bezitten. Ik besef dat zij in de afgelopen perioden de nodige aandacht te kort is 
gekomen. 


Ter afronding van het voorwoord merk ik op dat ik mij uiteraard gaarne aanbevolen houd 
voor op- en aanmerkingen betreffende het boek. 


Waalre, juli 1989 Bert de Brock 


0 WISKUNDIGE BASISBEGRIPPEN 


In dit hoofdstuk zullen we onze afspraken omtrent de betekenis van de door ons gebruikte 
basisbegrippen en -notaties vastleggen. We veronderstellen dat voor veel lezers de meeste 
van deze basisbegrippen wel min of meer bekend zijn; we beperken ons daarom ook meestal 
slechts tot het geven van de formele definitie van een in te voeren basisbegrip en het opsom- 
men van enige elementaire eigenschappen ervan, gewoonlijk in de vorm van een lemma 
(zonder bewijs). Wel is het mogelijk dat sommige "bekende" begrippen iets anders (of iets 
algemener) zijn gedefinieerd dan de lezer gewend is. 


Gezien het elementaire karakter van dit hoofdstuk hebben we hier geen opgaven opgenomen. 
(Wel kan uiteraard elk lemma worden opgevat als een opgave om dat lemma te bewijzen.) 
De lezer die behoefte heeft aan een uitgebreidere behandeling van de in dit hoofdstuk 
ingevoerde begrippen, verwijzen we naar bijvoorbeeld [DDS 75]. Ook Deel F1 


("Wiskunde") van [BPZ 87] geeft van deze begrippen diverse eigenschappen en voorbeel- 
den. 


0.1 VERZAMELINGEN 


Het elementaire begrip verzameling veronderstellen we bekend. We memoreren dat een ver- 
zameling geen ordening en geen duplicaten kent; ook doet de beschrijvingswijze van de 
elementen niet ter zake. Er geldt dus bijvoorbeeld 


(3,2,2, 1,2+1,2-1}= (3,2, 1} = (1, 2, 3}. 


2 WISKUNDIGE BASISBEGRIPPEN 


Ook de betekenis van de volgende uitdrukkingen veronderstellen we bekend: 


Uitdrukking | Betekenis 


xeA x is een element van A 

xéA x is geen element van A 

|A | het aantal elementen van A 

Ø de lege verzameling 

Z de verzameling van alle gehele getallen 
mmodn de rest van m na (gehele) deling door n 

m div n m gedeeld door n, met weglating van de rest 


Zo geldt voor elke m e Z en elke n e Z dat 

(mdivn)e Z, 

OS mmodn < nen 

m =n x(m div n)+m mod n. 

Verder zullen we nog gebruik maken van de volgende afkortingen: 


Notatie Betekenis 


Vxe A: | voor elk element x van A geldt: 
dxe A: | eris een element x van A waarvoor geldt: 


> dan en slechts dan als 
d> per definitie dan en slechts dan als 
2 is per definitie 


In plaats van "<=>" schrijven we ook wel eens "desda" (voor "dan en slechts dan als"). 
Verder merken we op dat we het symbool "O" gebruiken om het einde aan te geven van een 
voorbeeld, een bewijs of een serie opgaven. 


Met bovenstaande notaties kunnen we nu bijvoorbeeld de (ware) bewering dat er voor elk 
geheel getal een kleiner geheel getal bestaat als volgt op compacte wijze opschrijven: 


VxeZ:dyeZ:y<x 


Tenslotte veronderstellen we ook het begrip geordend paar bekend. Het geordende paar met 
x als eerste coördinaat en y als tweede coördinaat noteren we als volgt: (x ; y). Omgekeerd, 
als p een gegeven geordend paar is, dan kunnen we de eerste coördinaat van p aanduiden met 
u (p) en de tweede coördinaat van p met 2(p). 


VERZAMELINGEN 3 


We memoreren dat geordende paren gelijk zijn dan en slechts dan als zowel hun eerste 
coördinaten als hun tweede coördinaten gelijk zijn: 


iy) (x sy) desdax=x’ eny=y’. 
Dus (2; 3) # (3; 2), terwijl (2, 3} = {3, 2}. 


De verzameling van alle natuurlijke getallen (inclusief 0) duiden we aan met WN: 


DEFINITIE 0.0: 
IN= {ke Z\k2> 0}. 


Als n e IN, dan verstaan we onder Chs(n) de verzameling van alle tekenrijen (ofwel strings) 
die uit maximaal n tekens bestaan. Voor elke n e IN is de lege tekenrij, die uit 0 tekens be- 
staat, een element van Chs(n). Na Voorbeeld 0.2 (aan het eind van dit hoofdstuk) komen we 
nog op dit begrip terug. Voor elke n e IN is Chs(n) een eindige verzameling. 


We vervolgen onze notatie-afspraken met de formele definities van verzamelingsinclusie, de 
vereniging, de doorsnede, het verschil en het cartesisch produkt van twee verzamelingen en 
tenslotte de machtsverzameling van een verzameling: 


DEFINITIE 0.1: 
Als A en B verzamelingen zijn, dan: 


(a) ACB <> VxeA:xe B; 
b) BDA & AGB; 
(c) ACB ab AcBenA £B; 


@) AUB 2 {x\lxeAofxe B}; 

(ec) ANB = {x|xeA enxe B}; 
() A-B 2 {xlxeA enxe B}; 
(g) AXB = {(x;y)|xe Aenye B}; 
(h) P(A) 2 (XIXcA}. 


We merken op dat de elementen van een verzameling zelf ook verzamelingen kunnen zijn. 


P(A), de machtsverzameling van A, is een voorbeeld van zo’n verzameling van verzame- 
lingen. 


4 WISKUNDIGE BASISBEGRIPPEN 


In de volgende definities introduceren we notaties voor enige nuttige deelverzamelingen van 
Z: 


DEFINITIE 0.2: 
Alsme Z enne Z, dan: 


(a) [m.n] (ke Z Im<kenk< n); 
b) [m.n) (ke Z | mskenk <n}; 
O Im.) 2 {ke Z\mS<k}. 


DEFINITIE 0.3: 
Alsn e IN — {0}, dan: 


(a) Vng(n)= [10"-! .. 10" — 1); 
(b) Int(n) = [-(10"-1).. 10" — 1]. 


Dus, Vng(n) is de verzameling van alle natuurlijke getallen die (in het tientallig stelsel) uit 
precies n cijfers bestaan, en Int(n) is de verzameling van alle gehele getallen (ofwel integers) 
die in het tientallig stelsel uit maximaal n cijfers bestaan (het teken dus niet meegerekend). 
Bijvoorbeeld, 


Vng(4) = [1000 … 9999] en Int(4) = [-9999 … 9999]. 


Een veel gebruikte manier om sommaties op te schrijven is als volgt: 
D Ux 
x 


waarbij &, uitdrukt waarover er wordt gesommeerd en u, uitdrukt wat er wordt gesommeerd. 
Omdat in onze toepassingen de uitdrukkingen &, vaak lang zijn, zullen wij zo’n sommatie 
aldus schrijven: 


È, Ox | Ux 
Zo representeert bijvoorbeeld 
X ne [0.. 199] en (n mod 3) #0: n° 


de som van de kwadraten van alle natuurlijke getallen kleiner dan 200 die niet deelbaar zijn 
door drie. 


VERZAMELINGEN 5 


De definitie van de (gegeneraliseerde) vereniging van een verzameling van verzamelingen is 
een generalisatie van de definitie van de vereniging van twee verzamelingen (zoals zal 
blijken in Lemma 0.1 (2)). 


DEFINITIE 0.4: 
Als W een verzameling van verzamelingen is, dan: 
Uw2xidAeW:xe A}. 


Het volgende lemma beschrijft de speciale gevallen waarin de verzameling W uit 0, 1 of 2 
elementen bestaat. 


LEMMA 0.1: 

Als A en B verzamelingen zijn, dan: 
0) Us=e; 

(1) U{A}=4; 

(2) U{A, B}=AUB. 


Als R een verzameling geordende paren is, dan verstaan we onder dom(R), het domein van 
R, de verzameling van alle eerste coördinaten in R en onder mg(R), het bereik van R of de 
range van R, de verzameling van alle tweede coördinaten in R. Onder R™, de inverse van R, 
verstaan we de verzameling bestaande uit het "omgekeerde" van elk der elementen van R: 


DEFINITIE 0.5: 
Als R een verzameling geordende paren is, dan: 


(a) dom(R)= {x | (x;y) e R}; 
b) mg(R) = {y1 @;y)e R); 
() R!  2{0;x)l&œ;y)eR)}. 


Een verzameling geordende paren wordt in de wiskunde wel een relatie genoemd. We 
merken hierbij echter meteen op dat dezelfde term in database-theorie vaak wordt gebruikt 
voor datgene wat wij een tabel zullen noemen (in Definitie 1.1). 


Het volgende lemma geeft een aantal elementaire eigenschappen van het domein, het bereik 
en de inverse van enige samengestelde verzamelingen geordende paren weer. 


6 WISKUNDIGE BASISBEGRIPPEN 


LEMMA 0.2: 
Als R en P verzamelingen geordende paren zijn en D c R, dan: 


(a) RUP,ROAP,R-P,DenR™ zijn ook verzamelingen geordende paren; 
(b) dom(R U P)=dom(R) U dom(P) en mg(R U P) = mg(R) U mg(P); 

(c) dom(R NA P) c dom(R) ^ dom(P) en mg(R A P) c mg(R) A mg(P); 

(d) dom (R —P) 2 dom(R) — dom(P) en mg(R — P) > mg(R) — mg(P); 

(e) dom(D) c dom(R) en mg(D) c mg(R); 

(B) dom(R7') = mg(R) en mg(R~) = dom(r); 


(2) (RU PY!=R! U P! en(RA PY! =R" n P en 
(R - PY! =R! - P! en (RY! =R. 


0.2 FUNCTIES 


We definiëren het bekende begrip functie op de volgende wijze: 


DEFINITIE 0.6: 
F is een functie <> F is een verzameling geordende paren en 
Ix: ye F:V@'sy)eF: alsx=x’ dany=y’. 


Met andere woorden, F is een functie als F een verzameling geordende paren is waarvoor er 
bij elke x e dom(F) precies één y bestaat met (x;y) e F. Voor elke functie f en elke 
xe dom(f) is f(x) per definitie de eenduidig bepaalde y waarvoor geldt dat (x; y) e f. Lees 
f«) als: f toegepast op x. Omgekeerd is f inv y, het origineel van y onder f, de verzameling 
van alle x € dom(f) waarvoor geldt dat (x; y) € f. Dus, f inv y = {x e dom(f) | f(x)=y}. 


Een element van dom(f ) noemen we wel een argument van f en een element van mg(f) wel 
een waarde van f. In het bijzonder noemen we f(x) wel de waarde van f in x. Als f(x) =x 
dan noemen we x wel een dekpunt van f. 


Ter illustratie definiëren we de verzameling f1 als volgt: 


fl = ((EMPNO; 10), (DEPNO; 6), (SAL; 1962) } 


FUNCTIES 7 


Volgens Definitie 0.6 is fl een functie en f1(EMPNO) = 10, f1(DEPNO) = 6 en f1(SAL) = 
1962. De verzameling ((EMPNO; 10), (DEPNO; 6), (SAL; 1962), (DEPNO; 8)} is geen 
functie. Een eenvoudig (en klassiek) voorbeeld van een functie is ((x;x+1) lxe IN}, de 
zogeheten successorfunctie voor de natuurlijke getallen. De verzameling 
{((k; n); k74+n)l(kin)e ZX IN } is een voorbeeld van een functie "in twee variabelen". 


Omdat elke functie een verzameling geordende paren is, is elk begrip en elk lemma dat van 
toepassing is op verzamelingen in het algemeen of op verzamelingen geordende paren in het 
bijzonder, ook van toepassing op functies! Zo zijn bijvoorbeeld de doorsnede en de vereni- 
ging van twee functies gedefinieerd, evenals het domein en het bereik van een functie. 
Bijvoorbeeld, dom(f1) = {EMPNO, DEPNO, SAL} en rng(fl) = {6, 10, 1962}; van de 
eerder genoemde functie "in twee variabelen" is Z x IN het domein en IN het bereik. 


Verder is ook Lemma 0.2 van toepassing op functies. Zo zien we dat voor alle functies f en g 
zowel f U gals f A gen f —g verzamelingen geordende paren zijn. Maar zijn het ook func- 
ties? Op deze vraag gaan we nu nader in. 


LEMMA 0.3: 
Als fen g functies zijn en D c f, dan: 


(a) Dis een functie; 

(b) fA gen f—g zijn functies; 

(c) Img(f)!|s | dom(f) l; 

(d) @is een functie en dom(@) = mg(@) = Ø. 


De vereniging van twee functies hoeft blijkbaar geen functie te zijn. Ter illustratie definiéren 
we de functie f2 als volgt: 


f2 = {(DEPNO; 6), (SAL; 2100), (AGE; 26)}. 
Nu is fl U f2 geen functie, want zowel (SAL; 1962) e fl U f2 als (SAL; 2100) e fl U f2. 


Als fen g functies zijn waarvoor wel geldt dat f U g een functie is, dan noemen we f en g 
compatibel: 


DEFINITIE 0.7: 
Als fen g functies zijn, dan: 
fen g zijn compatibel <> f UV gis een functie. 
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In de Engelstalige database-literatuur worden functies die compatibel zijn ook wel joinable 
genoemd. We merken op dat elke functie compatibel met zichzelf is. Als de functies f en g 
compatibel zijn en de functies g en h ook compatibel zijn, dan hoeven fen h nog niet compa- 
tibel te zijn. (Ga dit na.) In Lemma 0.12 zullen we nog enige criteria geven opdat twee func- 
ties compatibel zijn. 


Het volgende lemma geeft nuttige criteria voor het bewijzen van inclusie of gelijkheid van 
functies: 


LEMMA 0.4: 

Als fen g functies zijn, dan: 

(a) fog desda dom(f) c dom(g) en Vx e dom(f): f(x)=g(x); 
(b) f=g desda dom(f)=dom(g) en Vx e dom(f) : f (x)= g (x). 


Onderdeel (a) is af te leiden uit Definitie 0.6 en onderdeel (b) volgt uit (a). 


Om het spreken over functies gemakkelijker te maken, introduceren we de volgende nomen- 
clatuur: 


DEFINITIE 0.8: 
Als A een verzameling is, dan: 


(a) fis een functie over A ee fis een functie en dom(f ) = A; 
(b) fis een functie uit A oe fis een functie en dom(f) c A; 
(c) fiseen functie naar A ps fis een functie en mg(f) c A; 


(d) fis een functie op A <> fis een functie en mg(f) = A. 


In de literatuur wordt een functie uit A ook wel een partiéle functie over A genoemd. Een 
functie over A noemen we ook wel een functie van A in uitdrukkingen zoals "functie van A 
naar B" en “functie van A op B". 


We merken op dat elke functie f een functie van dom(f) op mg(f) is. 


Voor elke verzameling A definiëren we id(A), de identieke functie op A, als de functie die 
aan elk element van A dat element zelf toevoegt: 
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DEFINITIE 0.9: 
Als A een verzameling is, dan: 
id (A) = {(x; x) Ive A}. 


LEMMA 0.5: 
Als A en B verzamelingen zijn, dan: 


(a) id(A) is een functie van A op A; 
(b) id(AUB)=id(A) U id(B); 

(c) id(AMNB)=id(A) ^A id(B); 

(d) id(A—B)=id(A) —id(B). 


De verzameling van alle functies van A naar B geven we aan met A —P> B en de verzameling 
van alle "partiële" functies van A naar B met A B: 


DEFINITIE 0.10: 
Als A en B verzamelingen zijn, dan: 


(a) A—>B £ {f1 fis een functie en dom(f) = A en mg(f) c B}; 
(b) AB? {f | fis een functie en dom(f) c A en mg(f) c B}. 


Uit de definitie volgt dat (A —> B) c (A — B). We kunnen deze notaties herhaald 
toepassen; zo is A —> (B —> C) de verzameling van alle functies die aan elk element van A 
een functie van B naar C toevoegen. Daarentegen is (A —> B) —> C de verzameling van 
alle functies die aan elke functie van A naar B een element van C toevoegen. 


In de literatuur wordt "f e A —> B" vaak geschreven als "f : A —> B" en A —PB wel als 
B, 


Als R een verzameling geordende paren is dan noemen we R injectief als er bij elke 
ye mg(R) precies één x bestaat met (x; y) € R: 


DEFINITIE 0.11: 
Als R een verzameling geordende paren is, dan: 
R is injectief V(x syyER:VOQ'sy)e R: als y =y’ danx =x’. 


Merk op dat bovenstaande eis in feite de omkering is van die in Definitie 0.6. 


Voor functies komt injectiviteit op het volgende neer: 
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LEMMA 0.6: 
Als feen functie is, dan: 
fis injectief <> Vx e dom(f): Vx’ e dom(f): als f(x) = f (x^) dan x =x’. 


Een injectieve functie wordt ook wel een injectie of een één-éénduidige functie genoemd. 


LEMMA 0.7: 
Als R een verzameling geordende paren is, dan: 


(a) Ris injectief desda R™ is een functie; 


(b) als R een injectieve functie is, dan | dom(R) | = | mg(R) |. 


Naar aanleiding van onderdeel (b) van het voorgaande lemma (en onderdeel (c) van Lemma 
0.3) memoreren we nog de volgende nuttige equivalenties: 


LEMMA 0.8: 

Als A en B verzamelingen zijn, dan: 

(a) 1A12 IB | desda3J3fe A-—PB:mg(f)=B; 

(b) IAI< IB | desdadfe APB: fis injectief; 

(c) lAl=lBldesdadfe A—>B :fisinjectief en mg(f) =B. 


De onder (c) genoemde functie wordt wel een bijectie van A op B genoemd: 


DEFINITIE 0.12: 

Als A en B verzamelingen zijn, dan: 

fis een bijectie van A op B PN fis een injectieve functie en 
dom(f)=A en mg(f)=B. 


We zullen de notatie "Ax € A : u," (waarbij u, een of andere uitdrukking in x voorstelt) 
soms gebruiken als afkorting voor "{(x; u,) | xe A}". Dus Axe A: u, representeert een 
functie over A. Zo kunnen we bijvoorbeeld de successorfunctie voor de natuurlijke getallen 
schrijven als Axe IN:x+1 en de eerder genoemde functie "in twee variabelen” als 
Mk;n)e Z XIN :k? +n. Verder kunnen we voor elke verzameling A de identieke functie 
op A nu ook als volgt omschrijven: 


id(A)=AxeEA:x 


Verder gebruiken we ook nog de notatie "Axe A en ò,: u,” (waarbij o, een of andere 
voorwaarde voor x voorstelt) als afkorting voor "{(x; u,) | xe Aend,}". 
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We definiëren de samenstelling (of compositie) van g na f voor elk tweetal functies fen g (en 
niet alleen maar indien mg(f) c dom(g), zoals gebruikelijk is): 


DEFINITIE 0.13: 
Als fen g functies zijn, dan: 
go f= (œ; gf) |x € dom(f) enf (x) € dom(g)}. 


In A-notatie: g o f=Ax e dom(f)en f(x) e dom(g) : g(f(x)). 


Een van de toepassingen van deze (wat ruimere) definitie van functiecompositie illustreren 
we aan de hand van de onderstaande functies h1 en (de reeds eerder genoemde) f1: 


h1 = {(AFDNR; DEPNO), (MEDEWNR; EMPNO), (WPL; CITY)} 
fl = ((DEPNO; 6), (EMPNO; 10), (SAL; 1962)} 


Uit bovenstaande definitie van functiecompositie volgt nu dat fl o hl de verzameling 
{(AFDNR; 6), (MEDEWNR; 10)} is. Verder geldt hl o fl = Ø want er is geen enkele x € 
dom(f1) met f1(x) e dom(h1). | 


Van het volgende lemma, dat diverse nuttige eigenschappen van functiecompositie opsomt, 
zal in latere hoofdstukken herhaaldelijk gebruik worden gemaakt. 


LEMMA 0.9: 
Als f, g enh functies zijn, dan: 


(a) go f iseen functie; 

(b) dom(ge f) c dom(f); 

(c) mglge f) c mgl); 

(d) als mg(f) c dom(g), dan dom(g o f) = dom(/); 

(e) als dom(g) c mg(f), dan mg(g o f) = mg(g); 

(ff) hegef)=lhegef, 

(g) als dom(f) =dom(g), dan dom(fe h) = dom(g o h); 

(h) foh=goh<>fo id(mg(h))=g o id(mg(h)); 

(i) alsfo h=go hendom(f) c mg(h), dan f c g; 

G) alsfo h=ge hendom(f)=dom(g) c mg(h), dan f = g. 


Uit het volgende lemma blijkt dat compositie met de identieke functie op B, zowel "vooraf" 
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als "achteraf", als het ware als een "filter" werkt. Verder zien we dat de compositie van de 
identieke functies op twee verzamelingen de identieke functie op de doorsnede van die ver- 
zamelingen is. 


LEMMA 0.10: 

Als feen functie is en A en B zijn verzamelingen, dan: 
(a) foidB) ={;y)e flxe B}; 

(b) idB)ef ={@syleflye By 

(c) id(A)o id(B) =id(A A B). 


Voor elke functie f en elke verzameling B noemen we de zojuist onder (a) genoemde ver- 
zameling de restrictie van f tot B, met andere woorden de verzameling van alle elementen 
van f waarvan de eerste coördinaat in B ligt. De restrictie van f tot B duiden we aan met 
f\ B; het andere deel van f duiden we aan met f+ B: 


DEFINITIE 0.14: 

Als f een functie is en B is een verzameling, dan: 
D 

(a) fl B={@a;y)e flxe B}; 
D 

(b) ftB={@;syleflxe B}. 


Bijvoorbeeld, fl | {EMPNO, SAL} = {(EMPNO; 10), (SAL; 1962)} en fl + {EMPNO, 
SAL} = ((DEPNO; 6)}; voor de functie hl geldt dat h1 | {EMPNO, SAL} = Ø en hl + 
{EMPNO, SAL} = hl (omdat EMPNO en SAL in h1 niet als eerste coördinaten voorko- 
men). 


LEMMA 0.11: 
Als feen functie is en B en B’ zijn verzamelingen, dan: 


(a) fI Bis een functie over dom(f) A B; 
(b) fB is een functie over dom(f ) — B; 
(c) f| Ben fB zijn compatibel; 

(d f=Q] BV GHB); 

(e) fB =Axedom(f)NB: f(x); 

(f) JFB =Axedom(f)-B: f(x); 
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(g) fB =f} (dom) B); 
(h) f{B=fe id(B); 

G) (PB) BR =ft UB’); 
Gj) CIBIB'=f| (B AB’); 
(k) (IBB =fl (B-B); 
d) fla=Øðenøð} B =ð; 
(m) ft =fenð}B =ø. 


Lemma 0.11(h) vertelt nog eens expliciet dat restrictie eigenlijk een speciaal geval van func- 
tiecompositie is. 


DEFINITIE 0.15: 

Als fen g functies zijn en A is een verzameling, dan: 
D 

f=gopA flA =g} A. 


We zeggen in bovenstaand geval wel dat f gelijk is aan g op A of dat f en g overeenstemmen 
op A. 


Soms is een gegeven functie f "niet helemaal" de functie die we willen hebben, in die zin dat 
er sommige paren (x ; y) ontbreken of dat er bij sommige argumenten nog niet de "goede" 
waarden horen. De op f toe te passen "correctie" kunnen we representeren door een functie. 
Het "correctieresultaat" definiëren we als volgt: 


DEFINITIE 0.16: 

Als fen g functies zijn, dan: 
D 

fog = (f$ dom) U g. 


Bijvoorbeeld, voor de eerder genoemde functies f1 en f2 geldt het volgende: 


f1 0 f2 = ((EMPNO; 10), (DEPNO; 6), (SAL; 2100), (AGE; 26)} en 
f2 0 fl = ((EMPNO; 10), (DEPNO; 6), (SAL; 1962), (AGE; 26)} 


We noemen f 8 g wel de mutatie (of modificatie) van f volgens g. 
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LEMMA 0.12: 
Als f, g enh functies zijn, dan: 


(a) fg is een functie over dom(f) U dom(g); 
(b) als dom(f) =dom(g), dan f 0 g = g; 

(c) $F0g)0h=f6(g 0h), 

d) fOS=O0f=f. 


We zijn nu ook in staat enige alternatieve omschrijvingen van compatibiliteit te geven. 


LEMMA 0.13: 

Als fen g functies zijn, dan zijn de volgende beweringen equivalent: 
(a) feng zijn compatibel; 

(b) fu gis een functie; 

(c) feng stemmen overeen op dom(f) ^ dom(g); 

(d) _dom(f Ng) =dom(f) A dom(g); 

e) fog=gOf, 

(It) TORES yg. 


Vanaf onderdeel (c) geeft dit lemma dus als het ware vier alternatieve definities van compa- 
tibiliteit. Uit het lemma blijkt ook dat compatibele functieparen diverse interessante eigen- 
schappen hebben. In Hoofdstuk 2 komen we op compatibele functieparen nog uitgebreid 


terug. Het volgende lemma geeft nog een aantal eigenschappen van compatibele func- 
tieparen weer. 


LEMMA 0.14: 

Als f, g enh functies zijn en fen g zijn compatibel, dan: 
(a) fe heng o hzijn compatibel; 

(b) GFeh)uU(geh)=(fugde h; 

(c) (he f)U (ho g)=ho (fUg). 


We merken op dat de waarde van een functie een verzameling of zelf(s) een functie kan zijn. 
Bijvoorbeeld, Ane IN: [0 .. (n—1)] is de “verzamelingswaardige" functie over IN die aan 
elk natuurlijk getal de verzameling van al zijn voorgangers in IN toevoegt, en 
Ane IN:(Ake Z :k") is de "functiewaardige" functie over IN die aan elk natuurlijk getal 
n de n-de machts-functie over Z toevoegt. 
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Een verzamelingswaardige“? functie noemen we ook wel gewoon een verzamelingsfunctie: 


DEFINITIE 0.17: 
F is een verzamelingsfunctie SF is een functie en 
Vx e dom(F) : F(x) is een verzameling. 


VOORBEELD 0.1: 
Ter illustratie geven we twee voorbeelden van verzamelingsfuncties. Deze functies, 
FM en FA, zullen we ook later nog herhaaldelijk gebruiken. Om "de fantasie te 
prikkelen" geven we na de verticale lijn aan waaraan u zou kunnen denken bij dit voor- 


beeld. 

FM = {(NR ; IN), identiteitsnummer van een medewerker 
(NAAM ; Chs(40)), naam 
(SAL ; IN), salaris 
(GESL ;{‘M’, ‘V’}), geslacht 
(AFDNR ; [1.. 99])} afdelingsnummer 

FA={(ANR _ ; WN), nummer van een afdeling 
(NAAM ; Chs(45)), afdelingsnaam 
(MANNR; N)} id. nummer van de manager 

O Voorbeeld 0.1. 


Als F een verzamelingsfunctie is, dan verstaan we onder II(F) de verzameling van alle func- 
ties over dom(F) die voor elke x e dom(F) een "keuze" uit de verzameling F (x) maken, en 
onder TI(F) de verzameling van alle functies die voor "sommige" x e dom(F) een keuze uit 
F (x) maken: 


(*) Voor lezers die bekend zijn met de axiomatische verzamelingenleer merken we op dat we hier een naieve 
verzamelingenleer gebruiken waarin we niet vooronderstellen dat alles een verzameling is. 
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DEFINITIE 0.18: 
Als F een verzamelingsfunctie is, dan: 


(a) II) k {f | fis een functie over dom(F) en Vx e dom(f): f (x) e F(x)}; 
(b) II(F) £ {f | fis een functie uitdom(F) en Vx e dom(f):f œ)e F(x)}. 


We noemen II(F) wel het gegeneraliseerde produkt van F. Uit de definitie volgt dat 
IF) c ÛCF). 


Voor de eerder genoemde verzamelingsfunctie FA is II(FA) de verzameling van alle functies 
van de vorm 
{(ANR; n), (NAAM; a), (MANNR; m)}, 


waarbij n e IN, ae Chs(45)enm e N. 


Voor alle verzamelingen A en B kunnen we met behulp van Definitie 0.18 en de functie 
Xa e A : B, dus de (constante) verzamelingsfunctie die aan elk element van A de verzame- 
ling B toevoegt, de in Definitie 0.10 ingevoerde begrippen ook als volgt beschrijven: 


LEMMA 0.15: 
Als A en B verzamelingen zijn, dan: 


(a) A—>B-=II (ae A:B); 
(b) A-&B=I(Aaec A:B). 


Als V een willekeurige verzameling functies is dan verstaan we onder He(V), de heading van 
V (of het totale domein van V), de vereniging van de domeinen van elk der elementen van V: 


DEFINITIE 0.19: 
Als V een verzameling functies is, dan: 


He(v) = U {dom(f) 1 fe V}. 
Zo geldt bijvoorbeeld dat He({f1, f2}) = (EMPNO, DEPNO, SAL, AGE}, waarbij 


fl = ((EMPNO; 10), (DEPNO; 6), (SAL; 1962)} 
f2 = ((DEPNO; 6), (SAL; 2100), (AGE; 26)} 


Het volgende lemma behandelt enige speciale gevallen. 
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LEMMA 0.16: 
Als A en B verzamelingen zijn en F is een verzamelingsfunctie, dan: 


(a) 
(b) 
(c) 
(d) 


0.3 


He (II(F))  =dom(F) als II(F) # Ø; 


He (A —>B) =A als B # Ø; 

He (A-Z) =@; 

He (@) =ø. 

DE TRANSITIEVE AFSLUITING VAN EEN RELATIE 


Alvorens we de transitieve afsluiting van een relatie definiëren voeren we eerst het begrip rij 


in: 


DEFINITIE 0.20: 
Als n e IN, dan: 
r is een rij ter lengte n <> r is een functie en dom(r) = [0 .. n). 


VOORBEELD 0.2: 


Voorbeelden van rijen zijn: 


rl = ((O; 37), (1; 29), (2; 37)} 
r2 = {(0; 29), (1; 37), (2; 37)} 
r3 = {(0; 29), (1; 37), (2; 37), (3; 29)} 


De functies r1 en r2 zijn rijen ter lengte 3 en r3 is een rij ter lengte 4. 
We noteren rijen soms ook wel als volgt: 


rl = <37; 29; 37> 
r2 = <29; 37; 37> 
r3 = <29; 37; 37; 29> 


We zien dat rl #12, r2 #r3 en r3 #r1. 


O Voorbeeld 0.2. 
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Voor elke n € JN vatten we ook Chs(n) op als een verzameling rijen: 
Chs(n) = {r | 3k e [0.. n]: ris een rij ter lengte k en g(r) c C}, 


waarbij C de (niet nader gespecificeerde) verzameling tekens is. Als we ter illustratie in 
Voorbeeld 0.2 het getal 37 door het ‘E’ -teken vervangen en het getal 29 door het ‘N’-teken, 
dan krijgen we de representaties van de strings ‘ENE’, ‘NEE’ en ‘NEEN’, respectievelijk. 


We merken op dat rijen kunnen worden gebruikt wanneer de eventuele duplicaten en de 
ordening der objecten relevant zijn, zoals in de voorgaande voorbeelden van getallenrijen en 
tekenrijen (waarin immers r1 # r2 en r2 #13). 


Als r en r’ rijen zijn met r c r’, dan noemen we r een beginstuk van r’ en, omgekeerd, r’ een 
verlenging van r. De naamgeving moge duidelijk worden uit Voorbeeld 0.2, waarin r2 c r3. 
Ook als r en r’ elementen van Chs(n) zijn, dan drukt r cr’ inderdaad uit dat de tekenrij r 
een beginstuk van de tekenrij r’ vormt; zie het zojuist gegeven voorbeeld van ‘NEE’ en 
‘NEEN’. 


We beëindigen de behandeling van rijen met de opmerking dat uit Definitie 0.20 blijkt dat de 
lengte van een rij r altijd Ir | is en dat Ø de enige rij ter lengte 0 is. 


DEFINITIE 0.21: 
Als n e IN—{0} en R is een relatie, dan: 
RTn L4 {(r(0); r(n)) | ris een rij ter lengte n + 1 en Vie [0..n): (ri);r(i+l)e R}. 


LEMMA 0.17: 
(a) R T1=R voor elke relatie R; 
(b) Ø T n =Ø voorelke n e N- {0}. 


VOORBEELD 0.3: 
We definiëren de relatie R1 als volgt: 


R1 = {(1; 2), (2; 3), (3; 4), (1; 4), (3; 1))} 


We kunnen zo’n verzameling geordende paren ook grafisch weergeven: 
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Figuur 0.1: Een grafische weergave van R] 


Uit Definitie 0.21 leiden we af dat 


R1 T 2 = {(1; 3), (2; 4), (2; 1), (3; 2), (3; 4)}, 
R1 T 3 = {(1; 4), (1; 1), (2; 2), (2; 4), (3; 3)} en 
R1 Î 4=RI 


Verder geldt voor elke m e N en elke k e {1,2,3} dat R1 Î (3m+kh=RI1Tk. 


O Voorbeeld 0.3. 


In termen van de grafische weergave van R kunnen we R 7 n nu informeel omschrijven als 
de verzameling (beginpunt; eindpunt)-paren van alle "wandelingen" van precies n stappen 
die in de grafische weergave van R mogelijk zijn. 


Onder de transitieve afsluiting van een relatie R verstaan we de verzameling (beginpunt; 
eindpunt)-paren van alle mogelijke niet-lege wandelingen in de grafische weergave van R. 
Voor de transitieve afsluiting van R gebruiken we de notatie Tcl(R), van het Engelse 
‘transitive closure". We noemen R cyclisch als er echte “rondwandelingen” in R mogelijk 
zijn; in het andere geval noemen we R acyclisch. 


DEFINITIE 0.22: 
Als R een relatie is, dan: 


(a) TAWEUI(R In Ine N-{0}}: 
(b) Riscyclisch <> (x;y) € Tel(R) : x =y; 
(c) Ris acyclisch <> V(x ‚ye TCHR): x #y. 


Wanneer we Definitie 0.22 (a) uitschrijven dan zien we (met behulp van Definitie 0.21) dat 
(x;y) € Tcl(R) indien er een n in IN—{0} en een rij r ter lengte n +1 zijn zodanig dat 
x =r(0) en y =r(n) en (r(i); r@i+1)) € R voor alle i in [0 .. n). 
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Voor R1 uit Voorbeeld 0.3 geldt dat 
Tcl(R1) = (R1 T Dv (R1 T 2) U (RI Î 3) = {1, 2, 3} x {1, 2, 3, 4}. 


De relatie R1 is dus cyclisch. 


LEMMA 0.18: 
Als R een relatie is, dan: 


(a) 
(b) 
(c) 
(d) 
(e) 


AS TOR): 

Tcl(Tcl(R)) = Tcl(R); 

Tcl(@) = @; 

als R acyclisch is, dan is R irreflexief (d.w.z. Vx;y)e R:x +y); 


R is acyclisch <> Tcl(R) is irreflexief. 


1 VAN TABELLEN TOT DATABASE-UNIVERSA 


In dit hoofdstuk zullen we achtereenvolgens de belangrijke basisbegrippen tabel, database- 
toestand en database-universum introduceren. 


1.1 TABELLEN 


Onder een tabel over een verzameling A verstaan we een verzameling functies over A: 


DEFINITIE 1.1: 
Als A een verzameling is, dan: 
T is een tabel over A &>T is een verzameling en 
MeT : tis een functie over A. 


Een element van een tabel wordt ook wel een tupel genoemd. 


VOORBEELD 1.1: 
Figuur 1.1(a) representeert een tabel T1 over (AFDNR, GESL, NAAM, NR, SAL} en 


Figuur 1.1(b) een tabel T2 over (ANR, MANNR, NAAM}. T1 heeft drie elementen en 
T2 heeft twee elementen. 
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JANSSEN | 2200 M 1 
3109 V 2 
2995 M 1 


JANSSEN 
(a) Een tabel over {NR, NAAM, SAL, GESL, AFDNR} 


DEKKER 
2 PLANNING T 
1 PRODUCTIE 9 


(b) Een tabel over {ANR, NAAM, MANNR} 


Figuur 1.1 
De twee elementen van T2 zijn de functies 


tl = {(ANR; 2), (MANNR; 7), (NAAM; ‘PLANNING’ )} en 
t2 = {(ANR; 1), (MANNR; 9), (NAAM; ‘PRODUCTIE’ )}. 


Dus t1(ANR) = 2, t1(MANNR) = 7, etcetera. We zien dat dom(t1) = dom(t2) = (ANR, 
MANNR, NAAM}, in overeenstemming met Definitie 1.1. 


Merk op dat T1 c II(FM) en T2 c II(FA), waarbij FM en FA de in Voorbeeld 0.1 
gedefinieerde verzamelingswaardige functies zijn. 


Bij NR, NAAM, SAL, GESL en AFDNR in Figuur 1.1(a) mag men achtereenvolgens 
denken aan medewerkersnummer, naam, salaris, geslacht en afdelingsnummer van een 
medewerker. Bij ANR, NAAM en MANNR in Figuur 1.1(b) mag men achtereenvol- 
gens denken aan afdelingsnummer, afdelingsnaam en medewerkersnummer van de 
manager van de afdeling. Noodzakelijk voor het formele begrip zijn deze 
"bijgedachten" uiteraard niet. 


O Voorbeeld 1.1. 


Omdat elke tabel een (speciale) verzameling is, is elk begrip dat is gedefinieerd voor ver- 
zamelingen ook van toepassing op tabellen. Zo kunnen we bijvoorbeeld spreken over de 
vereniging en de doorsnede van twee tabellen; zie ook $ 2.1.1. 
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Uit Definitie 1.1. volgt dat @ een tabel is over elke verzameling. (Ga dit na.) Echter, voor 
elke verzameling A en elke niet-lege tabel T over A is A de enige verzameling waarover T 
een tabel is. Het bewijs gaat als volgt: 

Stel dat T een tabel over A en over A’ is en dat T # Ø. Dan is er een tg € T; nu is tọ een func- 
tie over A en over A’. Dus dom(tg)=A en dom(tg) =A’. Conclusie: A’ =A. Dus A is de 
enige verzameling waarover T een tabel is. 


De opgaven 1.1 en 1.2 geven alternatieve omschrijvingen voor de begrippen "tabel" en 
“tabel over A". 


OPGAVEN 
- 1.1. Bewijs de onderstaande equivalentie (Hint: neem voor het "<="-gedeelte A = He(V).) 
V is een tabel <> V is een verzameling functies en 


yfe V:Vf'e V: dom(f)=dom(f’). 


1.2. Als A een verzameling is, dan: 
T is een tabel overA <> T CA —&B vooreen of andere verzameling B. 
Bewijs dit. (Hint: neem voor het "=>"-gedeelte B = U {rng(t) | t € T}.) 
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VOORBEELD 1.2: 
Figuur 1.1 kan worden opgevat als een weergave van (het relevante deel van) de toe- 
stand van een zekere (kleine) organisatie. Deze toestand kan formeel worden 


gerepresenteerd door een functie vl over een verzameling van twee elementen, zeg 
over (MEDEW, AFD}, zodanig dat 


vl (MEDEW) = T1 en v1(AFD) = T2. 
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Als verder g1 de functie over (AFD, MEDEW} is die wordt gedefinieerd door 


gl(AFD) | ={ANR, MANNR, NAAM} en 
gl(MEDEW) = {AFDNR, GESL, NAAM, NR, SAL}, 


dan noemen we vl een database-toestand (of kortweg DB-toestand) over g1. 


O Voorbeeld 1.2. 


We zullen het begrip DB-toestand definiéren voor een willekeurige verzamelingsfunctie g: 


DEFINITIE 1.2: 
Als g een verzamelingsfunctie is, dan: 
v is een DB-toestand over g Sv is een functie over dom(g) en 
VE e dom(g) : v (E) is een tabel over g (E). 


Omdat elke DB-toestand een functie is, is elk begrip dat is gedefinieerd voor functies ook 


van toepassing op DB-toestanden. Zo kunnen we bijvoorbeeld spreken over het domein en 
het bereik van een DB-toestand. 


OPGAVEN 
1.3. Wat is het domein en wat is het bereik van de DB-toestand v1 uit Voorbeeld 1.2? 


1.4. Kan een DB-toestand over meer dan één verzamelingsfunctie gedefinieerd zijn? 
(Denk aan de lege tabel.) 


O 
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1.3 DATABASE-UNIVERSA 


De DB-toestand v1 genoemd in Voorbeeld 1.2 representeert de toestand van de betreffende 
organisatie op een bepaald tijdstip. Als we aannemen dat we steeds in dezelfde kenmerken 
geïnteresseerd blijven, dan kan de toestand van de organisatie in kwestie altijd worden 
gerepresenteerd door een DB-toestand over g1. Omgekeerd representeert niet elke DB- 
toestand over g1 een toegestane toestand voor die organisatie. 


De (door de betreffende organisatie zelf te bepalen) verzameling toegestane toestanden is 
dus één of andere verzameling DB-toestanden over g1. Zo’n verzameling noemen we een 
database-universum (of kortweg DB-universum) over g1. In het algemeen: 


DEFINITIE 1.3: 
Als g een verzamelingsfunctie is, dan: 
U is een DB-universum over g <> Uis een verzameling DB-toestanden over g. 


Als U een DB-universum over g is, dan noemen we g het DB-skelet van U, een element E 
van dom(g) een tabelindex (of "tabelnaam") van U, g (E) de kop (of "heading") van E in U 
en een element van g (E) noemen we wel een attribuut (of "attribuutnaam") van E in U. Een 
element van U noemen we een DB-toestand conform U. 


VOORBEELD 1.3: 
We zullen voor de in Voorbeeld 1.2 genoemde organisatie een DB-universum VBU 
over g1 definiëren waarin de volgende eisen zijn verwerkt: 
(1) Elke medewerker wordt eenduidig bepaald door het medewerkersnummer. 
(2) Elke afdeling wordt eenduidig bepaald door het afdelingsnummer. 
(3) Elke afdeling wordt ook eenduidig bepaald door de afdelingsnaam. 


(4) Elk afdelingsnummer in de medewerkerstabel komt ook voor (als afdelingsnum- 
mer) in de afdelingentabel. 


(5) Elk managersnummer in de afdelingentabel komt ook voor als medewerkersnum- 
mer in de medewerkerstabel. 


Om ons DB-universum VBU te definiëren, maken we gebruik van de verzame- 
lingswaardige functies FM en FA uit het vorige hoofdstuk, van twee tabellenverzame- 
lingen WM en WA (die achtereenvolgens de toegestane medewerkerstabellen en de 
toegestane afdelingentabellen weergeven) en van een hulpfunctie HF (die vastlegt 
welke tabelindexen aan welke tabellenverzamelingen worden gekoppeld): 
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FM = {(NR ; IN), 
(NAAM ; Chs(40)), 
(SAL ; N), 


(GESL. -x (SMi NNN 

(AFDNR; [1 .. 99])}; 
FA = {(ANR ; IN), 

(NAAM ; Chs(45)), 


(MANNR ; IN}; 
WM = {T | T CII(FM) en 
VteT: Vt'eT: alst#t’ dant(NR) #?t’(NR)}; (1) 
WA = {T I T c II(FA) en 
VteT: Vr eT: alst #t’ dant(ANR) #t’(ANR) en (2) 


t (NAAM) # t’(NAAM)}; (3) 


HF = {(MEDEW; WM), 
(AFD ;WA)}; 


VBU = {v | ve TI(HF) en 
{m(AFDNR) | m e v(MEDEW)} c {a(ANR) | a e v(AFD)} en (4) 
{a(MANNR) | a e v(AFD)} c {m(NR) | m e v(MEDEW)}} (5) 


O Voorbeeld 1.3. 


Omdat elk DB-universum een (speciale) verzameling is, is elk begrip dat is gedefinieerd 
voor verzamelingen ook van toepassing op DB-universa. Bovendien is een DB-universum 
over een verzamelingsfunctie g formeel gezien tevens een tabel over dom(g): 


STELLING 1.1: 
Als g een verzamelingsfunctie is en U is een DB-universum over g, 
dan is U een tabel over dom(g). 


Bewijs: 

Uit Definitie 1.3 volgt dat U een verzameling is en 

uit Definitie 1.2 volgt dat elk element van U een functie over dom(g) is. 
Dus U voldoet aan Definitie 1.1. 


m 


De tabelindexen van U fungeren dus als de attributen van de "supertabel" U, de DB- 
toestanden als de tupels van die tabel en de tabellen in zo’n DB-toestand als de "attri- 
buutwaarden" in de tabel U. Zo is bijvoorbeeld VBU een tabel over (MEDEW, AFD}. 
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OPGAVEN 

1.5. Voor een DB-universum U over een verzamelingsfunctie g met E e He(U) definiëren 
we: 
(a) U is consistent <> U #3; 
(b) Eis consistent in U < Jy e U:v(E) + Ø; 


. e D . . 
(c) U is regulier <> U is consistent en 
VE’ e He(U) : E’ is consistent in U. 


Bewijs nu de volgende beweringen: 

(a) Als U consistent is, dan is dom(g) eenduidig bepaald. 

(b) Als E consistent in U is, dan is g(E) eenduidig bepaald. 
(c) Als U regulier is, dan is g eenduidig bepaald. 

Met “eenduidig bepaald" bedoelen we hier achtereenvolgens dat 
(a) dom(g) = dom(g’), (b) g(E)=g'(E), en (c) g =’ 


voor elke verzamelingsfunctie g’ waarover U ook een DB-universum is. 
1.6. Bewijs dat er in Opgave 1.5 telkens "dan en slechts dan" geldt. 


1.7. Geldt er voor elk DB-universum U dat 
U is regulier <> Jv e U : VE e He(U): v(E) # 5? 
(Geef voor elk van beide implicaties een bewijs dan wel een tegenvoorbeeld.) 


1.8. Ga na dat {@} een DB-universum is. Is {@} (formeel gezien) een regulier DB- 
universum? Zo ja, wat is dan het (eenduidig bepaalde) DB-skelet van {@}? 


1.9. Als U een niet-leeg DB-universum over g is, dan dom(g) = He(U). Bewijs dit. 


1.10. (a) Is de functie v1 uit Voorbeeld 1.2 een element van VBU? 
(b) Geef (nog) een element van VBU. 
(c) Is@een element van WM? En van WA? 


(d) Zijn er elementen v van VBU waarvoor geldt v (AFD) = @? 
Zo ja, welke zijn het? 
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r13. 


VAN TABELLEN TOT DATABASE-UNIVERSA 


Een verkooporganisatie wil gegevens bijhouden van haar klanten, van de artikelen die 
de organisatie te koop heeft, en van de orders die deze klanten voor deze artikelen bij 
deze organisatie plaatsen. 


Van elke klant wil men het klantnummer en de naam van die klant bijhouden. Elke 
klant wordt eenduidig bepaald door zijn klantnummer. Een klantnummer is een 6- 
cijferig getal; om precies te zijn: een element van Vng(6). 


Van elk artikel wil men het artikelnummer, de naam en de prijs bijhouden. Elk artikel 
wordt eenduidig bepaald door het (5-cijferige) artikelnummer. 


Van elke order wil men de volgende gegevens bijhouden: het ordernummer, het num- 
mer van de klant die de order heeft geplaatst, het nummer van het in de order 
genoemde artikel en het bestelde aantal exemplaren van dat artikel. (Dus per order 
wordt er slechts één artikel besteld, maar eventueel met meer exemplaren tegelijk.) 
Elke order wordt eenduidig bepaald door het (7-cijferige) ordernummer. Van elke 
order moet het klantnummer ook voorkomen in de klantentabel. Evenzo moet van elke 
order het artikelnummer in het artikelenbestand voorkomen. 


Verwerk deze informele (en niet geheel volledige) beschrijving tot de formele definitie 
van een DB-universum VBU2. 


Probeer zelf een (klein) DB-universum VBU3 voor een of andere organisatie te 
definiëren (bijvoorbeeld voor een sportvereniging of een onderwijsinstelling). 


We kunnen elke relatie R als volgt "converteren" naar een tabel over {1,2}: 
crt(R)= {{(1; x), (2;y)} | Œ; De R) 

Omgekeerd kunnen we elke tabel T over {1,2} "converteren" naar een relatie: 
ct(T)= {(t(1); 2) | te T) 


Uit de geconverteerde van een tabel over {1,2}, respectievelijk een relatie, kunnen we 
de oorspronkelijke tabel, respectievelijk relatie, op eenduidige wijze reconstrueren 
door "de andere" conversie toe te passen: 


(a) crt(ctr(T))=T voor elke tabel T over {1,2}; 
(b) ctr(crt(R))=R voor elke relatie R. 


Bewijs (a) en (b). 
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2.1 BEGRIPPEN BETREFFENDE TABELLEN 


2.1.1 Operaties op tabellen 


We zijn geinteresseerd in die operaties die aan een of meer tabellen weer een tabel toevoe- 
gen. 


Een tabel is een verzameling, dus alle operaties die toepasbaar zijn op verzamelingen zijn 
ook toepasbaar op tabellen. Vele van deze operaties voegen aan elke tabel ook weer een 
tabel toe (en kunnen dus herhaald worden toegepast). Enkele van deze operaties zullen we 
hier behandelen. 


In het algemeen is elke deelverzameling van een tabel over A weer een tabel over A (Lemma 
2.1); in het bijzonder zijn de doorsnede en het verschil van twee tabellen over A weer tabel- 


len over A (Lemma 2.2). Ook is de vereniging van twee tabellen over A weer een tabel over 
A (Lemma 2.3). 


LEMMA 2.1: 

Als A een verzameling is en T is een tabel over A en D c T, dan is ook D een tabel over A. 
Bewijs: 

T is een tabel over A en D cT, dus D is een verzameling en als t e D dan t e T, dus volgens 


Definitie 1.1 is dan t een functie over A. We zien dus dat naast T ook D aan Definitie 1.1 vol- 
doet. 


O 
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LEMMA 2.2: 
Als A een verzameling is en T en T’ zijn tabellen over A, dan zijn ook T A T’ en T-T’ 
tabellen over A. 


Bewijs: 
TOT’ cTenT -T cT, dus volgens Lemma 2.1 zijn T A T’ en T —T’ ook tabellen over 
A. 


O 


LEMMA 2.3: 

Als A een verzameling is en T en T’ zijn tabellen over A, dan is ook T U T” een tabel over A. 
Bewijs: 

T U T is een verzameling en als te T UT’ dant e Tofte T’; in beide gevallen is t echter 
een functie over A. Kortom, T U T’ voldoet aan Definitie 1.1. 


oO 
VOORBEELD 2.0: 
Voorbeelden van voornoemde constructies zijn (uitgaande van T1 en T2 uit Voorbeeld 
1.1% 
(a) {te T11t(NR) ¢ {a(MANNR) lae T2}}; 
(b) {te T11t(SAL) > 2500 en t(AFDNR) = 1}, ofwel 
(te T1 | (SAL) > 2500} A {t e T1 | t(AFDNR)= 1}; 
(c) {te T11t(NAAM) # ‘JANSSEN’ }, ofwel 
T1 — {t e T1 | :(NAAM)= ‘JANSSEN’ }; 
(d) {te T11t(GESL) = ‘V’ of t(AFDNR) = 1}, ofwel 
(te T1 | t(GESL) = ‘V’} U (te T1 | t(AFDNR)=1}. 
O Voorbeeld 2.0. 


Uit Lemma 2.1 blijkt dat het wegstrepen van een aantal "rijen" uit een tabel weer een tabel 
oplevert. Uit Lemma 2.4 zal blijken dat ook de “orthogonale” operatie van het wegstrepen 
van een aantal "kolommen" uit een tabel weer een tabel oplevert. 


De formele definitie van deze operatie luidt als volgt: 


DEFINITIE 2.1: 
Als T een verzameling functies is en B is een verzameling, dan: 


TBE {Bite T}. 
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We noemen T | B wel de projectie van T op B. Hoewel we T | B hebben gedefinieerd voor 
elke verzameling functies en voor elke verzameling B, zijn de interessante gevallen die 
waarin T een tabel over een verzameling A is en bovendien B c A. 


VOORBEELD 2.1: 
Figuur 2.1 representeert de projectie van de tabel T1 van Figuur 1.1(a) op de verzame- 
ling (GESL, AFDNR}. Merk op dat T1 {{AFDNR, GESL} minder elementen heeft 
dan T1. 


Figuur 2.1: De tabel T1 | {AFDNR, GESL} 
O Voorbeeld 2.1. 


LEMMA 2.4: 
Als A en B verzamelingen zijn en T is een tabel over A, dan: 


(a) Tf BiseentabeloverA NB; 

OG TFBS ITI, 

Bewijs: 

(a) TĪ B= {t]B |te T} en dus (volgens Lemma 0.11(a)) een verzameling functies over 
B A A; met andere woorden, T [B is een tabel over A A B. 


(b) Volgens Lemma 0.8(a) is het voldoende om een functie f met T als domein en T | B 
als bereik aan te geven. We nemen f=AteT :t\ B; het is duidelijk dat deze functie 
voldoet. 


o 


De volgende operatie wordt wel de natural join (letterlijk: "natuurlijke verbinding") 
genoemd: 


DEFINITIE 2.2: 
Als T en T’ verzamelingen functies zijn dan: 


D i ; 
TaT ={tutIteT ent eT entu r iseen functie} . 


We kwantificeren hier dus over alle paren (t; t’) e T x T’ waarvoor geldt dat t en t’ compati- 
bel zijn (zie Definitie 0.7). 
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VOORBEELD 2.2: 
Figuur 2.2 representeert 


(a) eentabel V1 over (a, b, c} met 4 elementen, 
(b) een tabel V2 over {b, c, d} met 5 elementen, en 


(c) V1 pq V2,een tabel over (a, b, c, d} bestaande uit 7 elementen. 


(c) V1 pa V2 


Figuur 2.2 


Dus, populair gezegd, elk element van V1 wordt "gecombineerd" met elk element van 
V2 dat er op {b,c} "net zo uitziet". Merk op dat elementen die in de andere 
verzameling geen "gelijkwaardige" tegenhanger hebben in het eindresultaat dus niet 
voorkomen. 


O Voorbeeld 2.2. 


Het volgende lemma geeft enige interessante eigenschappen van de natural join weer: 
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LEMMA 2.5: 
Als A, A’ en A” verzamelingen zijn en T is een tabel over A en T” is een tabel over A’ en T” 
is een tabel over A”, dan: 


(a) T p< Teen tabel over A U A’; 
(b) IT pa TIS ITI * ITI; 
(c) T D< T’=T’ œ< T, met andere woorden, de natural join is commutatief, 
(d) T œ< (7’ œ< T")=(T >< T^ pad T”, m.a.w. de natural join is associatief, 
le) .alsA =A‘. danT pd T°=T OT’; 
(ff) Tea T=TenT px {O}=T enT pd =Ø. 
Bewijs: 
(a) Uit de definitie van de natural join is het duidelijk dat T pq T’ een verzameling func- 
ties is. Als u e T >< T’, danzijnerte Tent e T’metu=tu?; 
dus dom(u) = dom(tut^) = dom(t) U dom(t’) = A U A’. 
(b) We definiëren f= {((t;t); tUH) Il (t;tD Ee TXT’ ent U ris een functie}; 
fis een functie en T pq T’ = mg(f) en dom(f) < T xT’; 
dus, mede dankzij Lemma 0.8(a): 
IT pq T’| = lmg(f)l S ldom(f)I SIT XT VSIT * 17/1. 
O T BS T. 
={tUt’lte T ent eT ent Uf is een functie} 
={(tUtliteT’ enteT ent?’ U t is een functie} 
=T’ DT. 
(d T pa (TT pa T") 


={tUxlteT enxe T pq T" ent Ux is een functie} 
={*tuU( Ur) |teT ent'e T’ ent” eT en 
t U t" is een functie ent U (t’U t”) is een functie} ; (1) 


(T >a T’) >a T” 
={yUt"lyeT PAT’ ent" e T” eny U t" is een functie} 
={tUnut"lteT ent eT ent"eT” en 

t U t’ is een functie en (t Ut’) U t” is een functie} ; (2) 


uit Lemma 0.3(a) blijkt dat in (1) en (2) de voorlaatste eis volgt uit de laatste eis en dus 
kan worden weggelaten. 
Daarna is het eenvoudig in te zien dat T >< (T’ pa T")=(T >< T^ D< T". 


De rest van het bewijs wordt (in Opgave 2.8) aan de lezer overgelaten. 


O 
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Om het praktische gebruik van joins te illustreren geven we nog een extra voorbeeld van een 


join. 


VOORBEELD 2.3: 


Als in Figuur 1.1 (a) van Voorbeeld 1.1 AFDNR wordt vervangen door ANR en 
NAAM door MEDEWNM dan ontstaat (de representatie van) een tabel T3. Volgens 
Lemma 2.5 (a) is nu T3 pq T2 een tabel over (NR, MEDEWNM, SAL, GESL, ANR, 
NAAM, MANNR}. Deze tabel heeft drie elementen en wordt weergegeven in Figuur 


ya 


JANSSEN 
JANSSEN 
DEKKER 


PRODUCTIE 
PLANNING 
PRODUCTIE 


2200 M 1 
3109 V 2 
2995 M 1 


Figuur 2.3: De tabel T3 pq T2 


Kennelijk bevat T3 pq T2 voor elke medewerker de gegevens van die medewerker 


plus de gegevens van diens afdeling. 


O Voorbeeld 2.3. 


In Voorbeeld 2.3 beschreven we op informele wijze een manier om uit een tabel een andere 
tabel te verkrijgen, namelijk door de "kolomnamen" te vervangen door andere kolomnamen. 
De vraag is nu hoe we deze (nuttige) operatie op tabellen formeel kunnen definiëren. Daartoe 
maken we gebruik van een "herbenoemingsfunctie" (of attributentransformatie) h die aan 


elke "nieuwe" kolomnaam b de door b vervangen oude kolomnaam toevoegt: 


DEFINITIE 2.3: 
Als T een verzameling van functies is en h is een functie, dan: 


Tooh= {tohiteT}. 


VOORBEELD 2.4: 


De in Voorbeeld 2.3 gebruikte attributentransformatie is de als volgt gedefinieerde 


functie h3 over (NR, MEDEWNM, SAL, GESL, ANR}: 


h3(ANR) = AFDNR, 
h3(MEDEWNM) = NAAM en 
h3(x) = x voor elke x e (NR, SAL, GESL}. 
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We merken op dat h3 een bijectie op (NR, NAAM, SAL, GESL, AFDNR}} is, dat is 
precies de verzameling waarover T1 een tabel is. De in Voorbeeld 2.3 beschreven tabel 
T3 kunnen we nu schrijven als T1 ee h3. Ter illustratie bekijken we het effect voor één 
van de elementen van T1 nog eens in detail; als t3 het element van T1 is waarvoor 
geldt t3(NR) = 9, dan zien we dat t3 o h3 inderdaad het gewenste gedrag heeft: 


t3 o h3(ANR) = t3(h3(ANR)) = t3(AFDNR) = 1. 


Figuur 2.4 geeft het voorgaande nog eens suggestief weer. 


NR | MEDEWNM | SAL | GESL ANR 
NR NAAM SAL | GESL | AFDNR 


(a) De attributentransformatie h3 


EME 


JANSSEN 
JANSSEN 


(b) De tabel T1 


IEEE 


DEKKER 2995 
2200 
3109 


JANSSEN 
(c) De tabel T1 œ h3 


JANSSEN 


Figuur 24 
O Voorbeeld 2.4. 


We benadrukken nog eens dat de attributentransformatie de oude attributen aan de nieuwe 
attributen toevoegt, en niet omgekeerd. 


Definitie 2.3 laat de mogelijkheid open om één "oud" attribuut te vervangen door twee of 
meer "nieuwe" attributen. Uit de definitie volgt dat het resultaat in dat geval is dat er als het 
ware "kopieën" van de oude kolom onder elk van die nieuwe attributen voorkomen. Deze 
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nieuwe attributen zijn dus eigenlijk "synoniemen" van elkaar. 


Lemma 2.6 bevestigt ons vermoeden dat herbenoeming van attributen in een tabel weer een 
tabel met evenveel elementen oplevert. 


LEMMA 2.6: 

Als h een functie is en T is een tabel over mg(h), dan: 
(a) Tee his een tabel over dom(h); 

©) ITehkl=IT |; 

(c) Teoh=@ desda T =Ø. 


Bewijs: 
(a) Uit Lemma 0.9, (a) en (d), blijkt dat voor elke t e T geldt dat t o h een functie is en, 
omdat mg(h) = dom(#), dat dom(t o h) = dom(h). Dus T © h is een tabel over dom(h). 
(b) Het is eenvoudig in te zien dat At € T: to heen functie van T op T his. 
De functie is tevens injectief: 
Stel dat te T en t'e T zodanig dat to h=t’o h, voor elke y e dom(t) geldt dat 
y e mg(h), met andere woorden, er is een x e dom(h) met h(x) = y; 
dus t(y) = t(h(x)) = t“(h(x)) = t'(y). Uit Lemma 0.4(b) volgt nu dat t = 7’. 
Kortom, de functie At e T: to hvanT op T © h is ook injectief (zie Lemma 0.6). 


(c) Dit volgt direct uit (b) omdat @ de enige verzameling is met 0 elementen. 


OPGAVEN 
2.1. (a) Kunnen we, de Lemma’s 2.2 en 2.3 samenvattend, zeggen dat zowel de vereni- 
ging als de doorsnede en het verschil van elk tweetal tabellen weer een tabel is? 


(b) Geef de vier in Voorbeeld 2.0 beschreven verzamelingen medewerkerstupels in 
woorden weer. 


2.2. Als A een verzameling is en W is een verzameling van tabellen over A, dan is ook _) w 
een tabel over A. Bewijs dit. 


2.3. Leg uit waarom T1 | {AFDNR,GESL} minder elementen heeft dan T1. 
(Vergelijk bijvoorbeeld Figuur 2.1 met Figuur 2.4 (b).) 
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2.4. 


E 


2.6. 


at 


2.8. 


29. 


Als T een verzameling functies is en B is een verzameling, dan: 
(a) T ÌB =Ø desda T = Ø; 

(b) T | B= {Ø} desda T + en B A He(T) = Ø. 

Bewijs dit. 


Geldt (b) van Lemma 2.4 ook als T een willekeurige verzameling functies is? 
(Geef een bewijs of een tegenvoorbeeld.) 


Bewijs dat voor alle verzamelingen A, B en B’ en voor alle tabellen T en T’ over A het 
volgende geldt: 


(a) (TUT) PB=(TPB)U (T PB); 
B) (TAT) PB CCT PB) A(T’ |B); 
©) (T-TIME 2 (TPB) -T |B); 
(d) (PB) |B =T | CNB). 


Geef voor de twee "ontbrekende" inclusies tegenvoorbeelden. 


De formule in Opgave 2.6(a) kan aldus worden verwoord: "Projectie is rechtsdistribu- 
tief over vereniging". 
(a) Is projectie ook "linksdistributief" over vereniging? 

(Geef eerst aan wat we hiermee zouden bedoelen.) 


(b) Is projectie linksdistributief over doorsnede of over verschil? 
Bewijs zelf de rest van Lemma 2.5. 


Als in Figuur 1.1(b) MANNR wordt vervangen door NR en NAAM door ANM dan 
ontstaat (de representatie van) een tabel T4. 


(a) Bepaal Tl >< T4. 
(b) Bepaal T3 >< T4. 


(c) Bepaal T1 >< TS en T3 pq TS, waarbij TS = T4 U {t5}, 
waarbij t5 = {(ANR; 3), (ANM; ‘INKOOP’), (NR; 7)}. 


(d) Geef een informele beschrijving van wat de tabellen T1 pq T5 en T3 pq TS 
achtereenvolgens voorstellen. 
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2.10. Bepaal de natural join van T1 en T2 uit Voorbeeld 1.1. Probeer ook een informele 


2.1 


pð 


2 De 


2.13. 


2.14. 


beschrijving te geven van wat T1 >< T2 kennelijk "voorstelt". 


. Bewijs dat voor alle verzamelingen A en A’ en voor alle tabellen T over A en T’ over A’ 


het volgende geldt: 

dn 

(b) alsT [| A’cT’ | A,dan(T pa T’) |A =T; 
(c) alsA’CA,danT pq F's {te Tli A eT) 
(d) as ANA =,dan IT pq T'I=IT i ITI. 


Gebruik de resultaten uit de vorige opgave om te bewijzen dat voor elk element v van 
het DB-universum VBU uit Voorbeeld 1.3 het onderstaande geldt. Hierbij is h3 de 
attributentransformatie die in Voorbeeld 2.4 aldus is gedefinieerd: 


h3(ANR) = AFDNR, h3 (MEDEWNM) = NAAM en 
h3(x) = x voor elke x e (NR, SAL, GESL}. 


Verder geldt voor het in Voorbeeld 1.2 geïntroduceerde DB-skelet gl dat g1(AFD) = 
{ANR, MANNR, NAAM}. 


(a) (v (AFD) >< (v (MEDEW) ee h3)) | g1(AFD) cv(AFD); 
(b) (v (AFD) >< (Y(MEDEW) © h3)) | dom(h3) = = v(MEDEW)  h3; 
(c) v(AFD) >< (v(MEDEW) eo {(MANNR; NR)}) = v(AFD). 


Als A een verzameling is en T is een tabel over A en B c Aen C CA, 
danT | BUC)c(T |B) Pa (TPC). 
Bewijs dit. 


Bewijs dat voor alle verzamelingen A en A’ en voor alle tabellen T over A en T’ en T” 
over A’ het volgende geldt: 


(a) TOA (T AT)=(T o4 TJAT pa T”); 
b) T pa (T'-T”) =(T Pa T’)-(T pa T”; 
(c) TP (TUT)=(T pa TÓ (T pe T^. 
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LF 


2.16. 


mals 


2.19. 


2.20. 


Opgave 2.14 kan aldus worden verwoord: "De natural join is linksdistributief over 
doorsnede, verschil en vereniging". 


(a) Is de natural join ook "rechtsdistributief" over verschil? 
(Formuleer eerst wat we hiermee zouden bedoelen.) 


(b) Is de natural join ook rechtsdistributief over doorsnede en over vereniging? 


Geef een formele definitie van de in Opgave 2.9 gebruikte attributentransformatie, dat 
wil zeggen een functie h2 zodanig dat T4 = T2 ee h2 (waarbij T2 de in Figuur 1.1 (b) 
gerepresenteerde tabel is). 


Als T een verzameling functies is en h en h’ zijn functies, dan: 
(a) Tee(ho h’)=(T œh) h’; 


(b) TeolhUh)e(Teeh) pd (T eeh’) als hen h’ compatibel zijn. 
Bewijs dit. 


. Bewijs dat voor alle functies h en voor alle tabellen T en T’ over mg(h) het volgende 


geldt: 

(a) (TUT)eeh=(T oh) U (T oh); 
(b) TAT) eh=(T oh) (T oh); 
(c) (T-T)œh =(T oo h)—(T' oh); 
(d) alsTcT’ danT eeh cg T oh; 


(e) als h injectief is, dan: 
TcT’<s>TeehcT’' oh, 


Bewijs het volgende: 
Als T een verzameling functies is en B is een verzameling en 4 is een functie, dan: 


(a) TB = Tee id(B); 
(b) (T œh) | B = T œ (hl B); 
(c) (T | B)œh = T œ (id(B) o h). 


Bewijs het volgende: 


Als A en A’ verzamelingen zijn en T is een tabel over A en 7’ is een tabel over A’ en h 
is een functie, dan: 
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(a) TDA T)ohc (Toh) BA (T eeh); 
(b) (T Dd T’)oh= (Toh) Dd (T’ oh) als AN A’ c mg(h). 


2.21. Leid uit de vorige opgave het volgende af: 
Als A en A’ verzamelingen zijn en T is een tabel over A en 7’ is een tabel over A’ en B 
is een verzameling, dan: 
(a) (T œ< T) | Bc(T | B) (T | B); 
b) T ATTESTE ta T B) alsANA’CB. 


2.22. Als T een verzameling functies is en B is een verzameling, dan definiëren we: 
D 
TEB= (t+B IteT}. 


Gebruik nu Lemma 0.11 en de eigenschappen van projectie als leidraad om enige 
eigenschappen van dit nieuwe begrip af te leiden. 


2.1.2 Momentane afhankelijkheid 


Als T een tabel over A is en B en C zijn deelverzamelingen van A, dan noemen we C 
momentaan afhankelijk van B in T desda elk tweetal elementen van T dat overeenstemt op B 
ook overeenstemt op C. We noteren dit kortheidshalve als volgt: B — C in T. (Deze notatie 
dient niet te worden verward met de notatie "B — C" uit Definitie 0.10; zie in dit verband 
ook Opgave 2.25(b).) De formele definitie luidt: 


DEFINITIE 2.4: 
Als A , B en C verzamelingen zijn en T is een tabel over A, dan: 


B>CinT &VYteT:W eT: alst] B =t |B dant} C=?) C. 


Hoewel we momentane afhankelijkheid in een tabel over A hebben gedefinieerd voor alle 
verzamelingen B en C, zijn de interessante gevallen die waarin B CA en C CA. (Formeel 
hebben we de andere gevallen ook niet eens nodig; zie Opgave 2.25(a).) 


VOORBEELD 2.5: 
Als we de in Voorbeeld 1.1 ingevoerde tabel T1 over {NR, NAAM, SAL, GESL, 
AFDNR} bekijken (zie Figuur 2.5), dan constateren we onder andere dat: 
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(a) {NR} > {NR, NAAM, SAL, GESL, AFDNR} in T1; 
(b) {SAL} > {NR, NAAM, SAL, GESL, AFDNR} in T1; 
(c) {GESL} — {AFDNR} in T1; 

(d) {AFDNR} > {GESL} in T1; 

(e) {NAAM, GESL} > {SAL} in T1; 

(© {NAAM, AFDNR} > (NR, SAL, GESL} in T1; 

(g) niet {NAAM} — (NR, SAL, GESL, AFDNR} in T1; 
(h) niet (AFDNR} — (NR, SAL, GESL, NAAM} in T1. 


JANSSEN V 2 
JANSSEN M 1 
DEKKER M 1 


Figuur 2.5: De tabel T] 


O Voorbeeld 2.5. 


We vervolgen met een viertal lemma’s; Lemma 2.7 bevat drie belangrijke basiseigenschap- 
pen van momentane afhankelijkheid, Lemma 2.8 geeft enige directe gevolgen ervan, Lemma 
2.9 behandelt de randgevallen en Lemma 2.10 tenslotte geeft een alternatieve karakterisering 
van momentane afhankelijkheid. 


LEMMA 2.7: 
Als A een verzameling is en T is een tabel over Aen B c Aen C cAenD CA, dan: 


(a) als C cB,danB >CinT; 
(b) alsB —CinTenC > DinT, danB >D inT, 
(c) B —CinT desda Yc e C :B > {c}inT. 


Bewijs: 
(a) Steldatte Tent’ e T zodanig dat t} B =t’} B; 
voor C c B geldt dan uiteraard ook t \ C =t’} C; 


dus B > CinT. 
b) B—CinT,dusVYteT:VteT:alst)\B=t|Bdant} C =r} C; (1) 
C >DinT,dusVteT:Vt'’e T:alst} C =r f C dant} D =fr} D; (2) 


uit (1) en (2) volgt Vt e T : Vt’ e T: alst} B =r] B dant} D=t’} D; 
dus B > DinT. 
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(c) tCar) C desda Vorë C : C=C 
anders gezegd, t| C =t] C desda Yc e C:t} {c}=r] {c}; daarom 
B => CinT 
<> Yte T: Vr eT:alst| B=t'} BdanYceC:t\] {c}=t’'} {c} 
<> VceC:VteT:Vf/eT:alst| B=t'} B dant} (c}=t’| {c} 
<> Yc e C:B > {c} inT. 

a 


LEMMA 2.8: 

Als A een verzameling is en T is een tabel over A en B cAenCcAenDgAenEcA, 
dan: 

(a) B —BinT; 

(b) alsB > CinTenBcD,danD >C inT; 

(c) alsB —CinTenDcC,danB 4DinT; 

(d) alsB > CinTenD >EinT,danB UD 54C VU EinT. 


Lemma 2.8 is rechtstreeks met behulp van Lemma 2.7 te bewijzen, dat wil zeggen zonder 
terug te grijpen op de feitelijke definitie van momentane afhankelijkheid. (Sterker nog, in 
zekere zin karakteriseren de eigenschappen in Lemma 2.7, de zogeheten Armstrong- 
axioma's, precies alle afhankelijkheidsstructuren die in tabellen mogelijk zijn; zie [Ar 74] 
voor de details.) 


Bewijs: 

(a) Neem C gelijk aan B in Lemma 2.7 (a). 

(b) B cD, dus D > Bin T volgens Lemma 2.7 (a); 
omdat ook B — C in T, volgt nu uit Lemma 2.7 (b) dat D > C inT. 

(c) Analoog aan het bewijs van (b). 

(dd B—CinTenBcBuD,dusB U D —> C in T volgens onderdeel (b); 
evenzo B UD > EinT; 
uit Lemma 2.7 (c) volgt nu dat 
(Yce C:BUD >  {c}inT) en (Ycee E:BUD >{c}inT); 
kortom, Vce CU E:BUD > {c}inT; 


tenslotte gebruiken we Lemma 2.7 (c) nog een keer om te kunnen concluderen dat 
BUD >CuUEinT. 


BEGRIPPEN BETREFFENDE TABELLEN 43 


LEMMA 2.9: 

Als A een verzameling is en T is een tabel over A en B < Aen C CA, dan: 
(a) BoCin@; 

(b) Bo @inT; 

(c) S—CinTdesdalT PCIS1. 


Bewijs: 

(a) Volgt direct uit Definitie 2.4. 

(b) Neem C gelijk aan @ in Lemma 2.7 (a). 

(c) @>CinT 
<> VteT:Vt'eT:alst! @=t’} O@dant)}C=t'}C_ (volgens Definitie 2.4) 
<> VteT:Vt'eT:als®@=Odant!C=t'}C (volgens Lemma 0.11(1)) 
<> VteT:VteT:t)}C=r}C 
“> VxeT[C:VreThC:x=x’ 
SST 1-81. 

O 


LEMMA 2.10: 
Als A een verzameling is en T is een tabel over A en B c A en C cA, dan: 
B > C in T desda {(t | B; t} C) | te T} is een functie. 


Bewijs: 

{(t/ B;t! C) | te T} is een functie 

<> VteT:Vt'e T:alst| B=t|Bdant} C=t’|C (volgens Definitie 0.6) 
<> B -> CinT (volgens Definitie 2.4) 
o 


In de vorige lemma’s "varieerden" we meestal de attributenverzamelingen "bij 
gelijkblijvende T". In het volgende lemma "variëren" we de tabel "bij gelijkblijvende attribu- 
tenverzameling", om te kijken in hoeverre momentane afhankelijkheid behouden blijft onder 
de operaties uit $ 2.1.1. In de opgaven 2.27 en 2.28 gaan we hierop door. 
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LEMMA 2.11: 
Als A een verzameling is en T is een tabel over Aen B c Aen C CAenB -C inT, dan: 


(a) alsT’cT,danB > CinT’; 

(b) als B’ een verzameling is zodanig dat B c B’, dan B + C inT | B’; 

(c) als A’ een verzameling is en T’ is een tabel over A’, dan B > CinT pq T’; 

(d) als heen functie is en B’ c dom(h) zodanig dat B c mg(h} B’), 
dan B’ — {a e dom(h) | h(a) € C}inT œh. 

OPGAVEN 

2.23. Bepaal alle momentane afhankelijkheden in de tabel T1 van Figuur 2.5 die van de 
vorm B —> {c} zijn, waarbij ce {NR, NAAM, SAL, GESL, AFDNR} -B en B 
minimaal is in de volgende zin: VB’ c B: als B’ > {c} in T1 dan B’ =B. 

2.24. Leg uit waarom de momentane afhankelijkheden van bovengenoemde vorm te zamen 
in wezen voldoende zijn om alle momentane afhankelijkheden in een tabel over een 
eindige attributenverzameling te kennen. 

2.25. Als A, B en C verzamelingen zijn en T is een tabel over A, dan: 
(a) BoCinT =(BNA)OS(COA)inT; 
(b) B —>CinB C. 
Bewijs dit. 

2.26. Bewijs Lemma 2.11. 


2.27. Laat aan de hand van een voorbeeld zien dat momentane afhankelijkheid in het 


2.28. 


algemeen niet behouden blijft onder de vereniging van twee tabellen over een zelfde 
verzameling A. 


Bewijs het volgende: 

Als A en A’ verzamelingen en T is een tabel over A en T” is een tabel over A’ en BCA 
enC CANA’ enD CA’, dan: 

als B > CinTenC >DinT’,danB >DinT p< T. 
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2.1.3 Unieke identificatie 


Als T een tabel over een verzameling A is en B CA dan noemen we B uniek identificerend 
(of kortweg u.i.) in T desda twee verschillende elementen van T altijd verschillende restric- 
ties tot B hebben. Unieke identificatie is in feite een (belangrijk) speciaal geval van momen- 
tane afhankelijkheid (zie Lemma 2.12). We noemen B minimaal u.i. in T desda B ui. in T is 
en elke echte deelverzameling van B niet u.i. in T is. De formele definities van deze begrip- 
pen luiden als volgt: 


DEFINITIE 2.5: 
Als A en B verzamelingen zijn en T is een tabel over A, dan: 
Bisui.inT <>VteT:Vt'e T: als t|B=t'|Bdant=t. 


DEFINITIE 2.6: 
Als A en B verzamelingen zijn en T is een tabel over A, dan: 
B is minimaal u.i. in 7 <B is u.i. in Ten 

VB’ cB :B’ is niet ui. in T. 


VOORBEELD 2.6: 
Voor de tabel T1 uit Voorbeeld 2.5 geldt het volgende: 


(a) {NAAM, NR} is ui. in T1; 

(b) {NAAM, SAL} is u.i. in T1; 

(c) {NAAM} is niet u.i. in T1; 

(d) {GESL, AFDNR} is niet u.i. in T1; 


(e) elk van de verzamelingen {NR}, {SAL}, (NAAM, GESL} en {NAAM, 
AFDNR } is minimaal u.i. in T1; 


(£) geen enkele andere verzameling (dan de onder (e) genoemde) is minimaal u.i. in 
Fi, 


O Voorbeeld 2.6. 


De volgende lemma’s sommen enkele eenvoudige eigenschappen van unieke identificatie 
op. De meeste eigenschappen volgen direct uit de lemma’s in $ 2.1.2. 
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LEMMA 2.12: 
Als A een verzameling is en T is een tabel over Aen B c Aen C < Aen D CA, dan: 


(a) Bisui.in7desdaB > AinT; 

(b) Bisui.inTdesdaVae A —B : B —> {a} inT; 

(c) Aisui. in 7; 

(d) als B ui in Tisen B c C, dan is C ui. in 7; 

(e) als B u.i. in TisenC —BinT, dan is C wi. in 7; 

(ff) alsB > CinTenD => (A-C)inT, danis B U Dui. in 7; 
(g) @Misu.i.inT desda |7T1< 1. 


LEMMA 2.13: 

Als A een verzameling is en T is een tabel over A en B c A en B is ui. in T, dan: 
(a) als T’cT, danis B ui. in T’; 

(b) als B CB’, danis B u.i. inT | B’; 


(c) als heen functie is en B c mg(h), dan is dom(h) u.i. in T eo A. 


LEMMA 2.14: 


Als A en A’ verzamelingen zijn en T is een tabel over A en 7’ is een tabel over A’ en BCA 
en B’ c A’ enB is ui. in Ten B’ is wi. in T’, dan: 


(a) BUB iui iT od T: 
(b) als B’ cA, danis B u.i.inT pq 7’. 


We zullen hier alleen Lemma 2.14 (a) bewijzen. De andere bewijzen worden in de opgaven 
gevraagd. 


Bewijs van Lemma 2.14 (a): 


B is u.i. in T en B’ is ui. in T’, (gegeven) 

dus B — A in Ten B’ >A’ inT’, (volgens Lemma 2.12 (a)) 

dus B => A in T pq T’enB’ —A'inT’' œ< T, (volgens Lemma 2.11 (c)) 
dus B UB’ > A uU A’'inT pq 7’, (volgens Lemma 2.8 (d), en Lemma 2.5 (c)) 
dus B U B’ is u.i. in T pa T’ (volgens Lemma 2.12 (a), en Lemma 2.5 (a) 


e 
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OPGAVEN 


2.29. Herschrijf de definities van WM en WA uit Voorbeeld 1.3 in termen van unieke 
identificatie. 


2.30. Ga voor elk van de volgende tabellen na welke verzamelingen minimaal uniek 
identificerend in die tabel zijn. 


(a) T2 uit Voorbeeld 1.1; 
(b) TS uit Opgave 2.9 (c). 


2.31. Bewijs Lemma 2.12. 
2.32. Bewijs Lemma 2.13. 
2.33. Bewijs Lemma 2.14 (b). 


2.34. Momentane afhankelijkheid is ook in termen van unieke identificatie te definiëren, 
want voor alle tabellen T en alle verzamelingen B en C geldt: 


BoCinT <>BisuiinT | (BUC). 
Bewijs dit. 


2.35. Bewijs onderstaande equivalenties (cf. Opgave 1.13). 
Als R een relatie is, dan: 


(a) R iseen functie <> {1} is u.i. in crt(R); 


(b) Risinjectief <> {2} is u.i. in crt(R). 


2.1.4 Het verbindingsbegrip 
Het volgende nieuwe begrip leiden we in met een voorbeeld. 


VOORBEELD 2.7: 
In Voorbeeld 1.1 konden we constateren dat elke "(ANR; MANNR)-combinatie" in de 
tabel T2 ook voorkomt als "(AFDNR; NR)-combinatie" in de tabel T1, zie ook Figuur 
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2.6. Anders gezegd, de projectie van T2 op (ANR, MANNR} is "bijna" een deelver- 
zameling van de projectie van T1 op (AFDNR, NR}, namelijk op een herbenoeming 
van de attributen na. De bedoelde herbenoeming kunnen we weergeven door de vol- 
gende attributentransformatie: 


= ((ANR; AFDNR), (MANNR; NR)} 


De attributentransformatie h4 voegt dus aan elk der relevante attributen van T2 het 
"corresponderende" attribuut van T1 toe. Volgens onze definitie van functiecompositie 
geldt nu dat de projectie van T2 op (ANR, MANNR} wél een deelverzameling van de 
“herbenoemde" tabel {t o h4 | te T1} is. (Dit is namelijk wel een tabel over (ANR, 
MANNR}.) Met behulp van Definitie 2.3 kunnen we nu onze aanvankelijke constate- 
ring als volgt formeel weergeven: 


T2 | dom(h4) c T1  h4 


We zeggen in dit geval wel dat de attributentransformatie h4 de tabel T2 verbindt met 
de tabel T1. 


JANSSEN 
DEKKER 
JANSSEN 


Figuur 2.6: De attributentransformatie h4 verbindt T2 met T1 


O Voorbeeld 2.7. 


De algemene definitie van het verbindingsbegrip luidt als volgt: 
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DEFINITIE 2.7: 
Als T en T’ verzamelingen functies zijn en h is een functie, dan: 
h verbindt T met T’ <>T | dom(h) CT’ ooh. 


Twee iets minder compacte formuleringen zijn: 
(1) h verbindt T met T’ <> {t{ dom(h) lte T}c{tohltť eT} 
(2) h verbindt T met T’ <> Vte T:AteT':t|dom(h)=t o h. 


In de speciale gevallen waarin wij meestal zijn geinteresseerd is T een tabel over een ver- 
zameling A, T’ een tabel over een verzameling A’ en h een injectieve functie waarbij 
dom(h) c A en mg(h) c A’. Zij nu B = dom(h) en B’ = mg(h), dan kunnen we de volgende 
informele beschrijving van het verbindingsbegrip geven: 


h verbindt T met T’ dan en slechts dan als alle B-waarden in T ook voorkomen als B’- 
waarden in T’, waarbij h aangeeft welk attribuut in B correspondeert met welk attribuut in 
B’. 


In de praktijk zal mg(h) vaak uniek identificerend in T’ zijn. Bovendien zijn de attributen in 
B vaak gelijk aan de corresponderende attributen in B’; in dat geval is h dus de identieke 
functie op B. 


In sommige situaties is er bij verbinding niet alleen sprake van inclusie (zoals in Definitie 
2.7) maar zelfs van gelijkheid. We zeggen dan: h verbindt T bilateraal met T’. Zo verbindt in 
Voorbeeld 2.7 de functie ((AFDNR; ANR)} de tabel T1 bilateraal met T2. 


DEFINITIE 2.8: 
Als T en T’ verzamelingen functies zijn en h is een functie dan: 
h verbindt T bilateraal met T’ <> T | dom(h) =T’ œh. 


Voor een injectieve functie h is bilaterale verbinding eenvoudig uit te drukken in termen van 
“gewone” verbinding: 


LEMMA 2.15: 
Als T en T’ verzamelingen functies zijn en h is een injectieve functie, dan: 
h verbindt T bilateraal met T’ <> h verbindt T met T’ en h~! verbindt T’ met T. 


Het bewijs van dit lemma wordt in de opgaven aan de lezer overgelaten. 


Als T en T’ verzamelingen functies zijn en h is een functie, dan noemen we 
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{(t;t’)e TXT |t| dom(h)=t'o h} 


de door h geïnduceerde associatie op T XT’ (of tussen T en T’). 


Informeel verwoord is het dus de verzameling van alle tupelparen die "bij elkaar passen" in 
de zin van het "criterium" A. 


Met behulp van deze geïnduceerde associatie kunnen we nu eenvoudige alternatieve 
omschrijvingen geven van de begrippen verbinding en bilaterale verbinding, zie het vol- 
gende lemma. Tevens blijkt unieke identificatie van rng(h) in T’ of van dom(h) in T interes- 
sante eigenschappen van de geïnduceerde associatie tot gevolg te hebben. 


LEMMA 2.16: 


Als T en T’ verzamelingen functies zijn en h is een functie en R is de door h geïnduceerde 
associatie op T x T’, dus 


R={(t;t)eT xT’ | tl dom(h)=t ° h}, 


dan: 
OREERT 
(1) h verbindt T met T’ <> dom(R) =T; 


(2) h verbindt T bilateraal met T” <> dom(R) =T en mg(R) =T"; 
(3) als mg(h) u.i. in T’ is, dan is R een functie; 


(4) als dom(h) u.i. in T is, dan is R injectief. 


Bewijs: 
(0) Het volgt direct uit de beschrijving van R dat R cT xT’. 
(In het bijzonder geldt dus dat dom(R) c T en mg(R) c T”.) 
(1) h verbindt T met T’ 
<> (tl dom(h)lteT}e{(tehltetT’)} 
<> VteT:dteT':t|\ dom(h)=t'o h 
<> T c dom(R); 
(1) volgt nu uit (0) en de voorgaande equivalenties. 
(2) h verbindt T bilateraal met T’ 
<> (tl dom(h)lteT}={(t'ohlteT’)} 
<> (VteT:dt’'eT’:t} dom(h)=t’o h)en 
(Vt'e T :J3teT:t\dom(h)=t o h) 
<> T c dom(R) en T’ c mg(R); 
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(2) volgt nu uit (0) en de voorgaande equivalenties. 


(3) Stel(t;tDe Ren(t;t”)e R; we moeten nu bewijzen dat t’ = t”. 
Uit (t; De Ren (t; t”) e R volgt dat te T’ ent” e T’ en dat t| dom(h) =?’ o hen 
t| dom(h) =t” o h; 
dus t’o h =t” o h; hieruit volgt dat t) mg(h) =t” | mg(h); 
uit het gegeven dat mg(h) u.i. in T’ is volgt nu dat t’ = t”. 


(4) Stel(t;t)e Ren(s; t’) € R; we moeten nu bewijzen dat t = s. 
Uit (t; t’)e R en (s;t’)e R volgt dat te T en s e T en dat t} dom(h)=t o h en 
s | dom(h) =t o h; 
dus t | dom(h) = s | dom(h); 
uit het gegeven dat dom(h) u.i. in T is volgt nu dat t = s. 


OPGAVEN 
2.36. Ga voor elk van de onderstaande beweringen over de tabellen T1 en T2 uit Voorbeeld 
2.7 de juistheid na. 
(a) {(ANR; AFDNR)} verbindt T2 met T1; 
(b) {(AFDNR; ANR)} verbindt T1 met T2; 
(c) {(MANNR; NR)} verbindt T2 met T1; 
(d) {(NR; MANNR)} verbindt T1 met T2; 
(e) h47! verbindt T1 met T2. 


2.37. Beantwoord de volgende vragen over de attributentransformatie h4 uit Voorbeeld 2.7. 
(a) Isdom(h4) (minimaal) u.i. in T2? 
(b) Isrng(h4) (minimaal) u.i. in T1? 


(c) Is de door h4 geïnduceerde associatie op T2 x T1 een injectieve functie van T2 
op T1? (Controleer hierbij elk van de vier onderstreepte eigenschappen.) 


2.38. Geldt voor elk tweetal tabellen T en 7’: Ø verbindt T met T’? 


2.39. Als T en T’ verzamelingen functies zijn en h is een functie en h verbindt T met T’ en 
h’ c h, dan verbindt ook h’ de verzameling T met T’. Bewijs dit. 
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2.40. Bewijs Lemma 2.15. 


2.41. Geldt in Lemma 2.16, (3) en (4), ook "dan en slechts dan"? 
(Geef een bewijs dan wel een tegenvoorbeeld.) 


2.42. Herschrijf de definitie van VBU in Voorbeeld 1.3 met behulp van (bilaterale) verbin- 
ding. 


O 
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2.2 BEGRIPPEN BETREFFENDE TABELLENVERZAMELINGEN 


De begrippen uit §2.1.2 en §2.1.3, die zijn gedefinieerd voor tabellen, zullen we in §2.2.1 en 
§2.2.2 generaliseren tot een analogon op het niveau van tabellenverzamelingen. Om de ver- 
schillende niveaus goed te onderscheiden - hetgeen in de literatuur en in de praktijk vaak niet 
of nauwelijks gebeurt - zullen we voor overeenkomstige begrippen op verschillende niveaus 
telkens verschillende termen gebruiken. 


In Voorbeeld 1.3 zagen we reeds twee tabellenverzamelingen, te weten de verzamelingen 
WM en WA. Voordat we de afzonderlijke begrippen betreffende tabellenverzamelingen 
introduceren, geven we eerst nog een voorbeeld van een tabellenverzameling. 


VOORBEELD 2.8: 
We definiéren de tabellenverzameling WP (betreffende personen) met behulp van een 
viertal hulpfuncties, in casu F1, F2, F3 en F4. De functies F1, F2 en F3 worden 
gebruikt in de definitie van de objectkarakterisering F4. Naast de definities zullen we 
ook weer enige informele toelichting geven. 


Definities Toelichting 
F1 = {(STR ; Chs(50)), straat 
(HNR ; [1 … 5000) }; huisnummer 
F2={(NR ; [1000 .. 99997), nummer van een postcode 
(LC; CHOE letters van een postcode 
F3={(DG ;[i..31)), dag 
(MND; [1 .. 12]), maand 
GR ; N) jaar 
F4={(NR ; N-{0}), identiteitsnummer 
(NM_; Chs(40)), naam 
(ADR ; II(F1)), adres 
(PC ;II(F2)), postcode 
(WPL ; Chs(30)), woonplaats 
(GBD ; II(F3)), geboortedatum 
(GPL ; Chs(30)), geboorteplaats 


(NMK; P (Chs(30)))}; namen der kinderen 
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WP = {T cII(F4) | {NR} is u.i. in Ten 
{PC} — {WPL} in Ten 
(ADR, WPL} — {PC} in T en 
Vt e T: als (NR) # 1 dan Jt’ e T: t’(NR) = (NR) — 1} 


Figuur 2.7 representeert een element TP van WP. 


E.F. CODD 
C.J. DATE 
R. FAGIN 

M.E. SENKO 


PARKLAAN 
SCHOOLWEG 


(JAN, PIET, EL 
(AN, JAN} 
(MARIE) 


Figuur 2.7: De tabel TP, een element van WP 
O Voorbeeld 2.8. 


We hebben in Voorbeeld 2.8 tevens laten zien dat attributen zelf weer "subattributen” kun- 
nen hebben, namelijk als de attribuutwaarden functies zijn. Voorbeelden zijn de attributen 
ADR, PC en GBD met als verzamelingen subattributen respectievelijk (STR, HNR}, (NR, 
LC} en (DG, MND, JR}. In principe kunnen we zo’n "nesting" van attributen natuurlijk wil- 
lekeurig diep maken. Of de huidige database-managementsystemen dergelijke constructies 
ook aankunnen is echter een heel andere vraag. 


2.2.1 Permanente afhankelijkheid 


We noemen het analogon van momentane afhankelijkheid op het niveau van tabellenver- 
zamelingen permanente afhankelijkheid. In het bijzonder noemen we C permanent 
afhankelijk van B in W als C momentaan afhankelijk is van B in elk element van W. We noe- 
men permanente afhankelijkheid ook wel structurele afhankelijkheid (en momentane 
afhankelijkheid ook wel incidentele afhankelijkheid). Ter onderscheiding van de notatie 
"B > C in T" voor momentane afhankelijkheid in een tabel T gebruiken we voor het gege- 


neraliseerde begrip, permanente afhankelijkheid in een tabellenverzameling W, de notatie 
"B>CinW". 
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DEFINITIE 2.9: 
Als A, B en C verzamelingen zijn en W is een verzameling tabellen over A, dan: 
B3CinW &YTeW:B>CinT. 


Evenals bij Definitie 2.4 zijn ook hier de interessante gevallen weer die waarin B c A en 
CEA. 


In de database-literatuur wordt vaak de term functionele afhankelijkheid gebruikt; op vele 
plaatsen is het echter niet duidelijk of daarmee momentane afhankelijkheid dan wel per- 
manente afhankelijkheid wordt bedoeld. 


VOORBEELD 2.9: 
Met de tabellenverzameling WM van Voorbeeld 1.3 in gedachten laten we de in Voor- 
beeld 2.5 genoemde momentane afhankelijkheden in de tabel T1 eens de revue 
passeren. We kunnen dan uit de definitie van WM concluderen dat de in Voorbeeld 
2.5(a) genoemde momentane afhankelijkheid in Tl ook een permanente 
afhankelijkheid in WM is: 


(a) {NR} > {NR, NAAM, SAL, GESL, AFDNR} in WM. 


De afhankelijkheden genoemd in (g) en (h) van Voorbeeld 2.5 bleken al niet te gelden 
in T1, en dus zeker niet in WM (want T1 e WM). Ook voor de andere 
afhankelijkheden kunnen we echter tegenvoorbeelden geven. Zij bijvoorbeeld T12 de 
tabel die we uit de tabel T1 verkrijgen door van het tupel met medewerkersnummer 8 
het afdelingsnummer te veranderen van 1 in 2; zie Figuur 2.8. Het is dan eenvoudig na 
te gaan dat T12 e WM. Echter, de afhankelijkheden in (c), (d) en (f) van Voorbeeld 2.5 
gelden niet in T12, en daarmee dus ook niet in WM. De gevallen (b) en (e) worden in 
Opgave 2.44 behandeld. 


JANSSEN | 3109 
2200 
2995 


JANSSEN 
Figuur 2.8: De tabel T12 


DEKKER 


O Voorbeeld 2.9. 
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OPGAVEN 


2.43. 


2.44. 


245. 


Deze opgave gaat nader in op Voorbeeld 2.8 aan het begin van 82.2. 

(a) Geef de eis in de laatste regel van de definitie van WP in woorden weer. 
(b) Heeft WP oneindig veel elementen? 

(c) Heeft WP oneindig grote elementen? 


(d) Heeft WP eindige elementen van elke grootte? 


Zij F40 de objectkarakterisering die we verkrijgen door in de definitie van F4 in Voor- 
beeld 2.8 de verzameling IN — {0} te vervangen door IN en zij WPO de tabellenver- 
zameling die we verkrijgen door in de definitie van WP het gegeneraliseerde produkt 
II(F4) te vervangen door II(F40). 


(e) Gana of II(F4) bevat is in II(F40), en omgekeerd. 
(f) Gana of WP bevat is in WPO, en omgekeerd. 


Zij nu FI de objectkarakterisering die we verkrijgen door in de definitie van F40 de 
verzameling JN te vervangen door Z en WI de tabellenverzameling die we verkrijgen 
door in de definitie van WPO het gegeneraliseerde produkt II(F40) te vervangen door 
TICFD. 


(g) Gana of II(F40) bevat is in TI(FI), en omgekeerd. 
(h) Gana of WPO bevat is in WI, en omgekeerd. 


Toon aan dat de momentane afhankelijkheden genoemd in (b) en (e) van Voorbeeld 2.5 
geen permanente afhankelijkheden in WM zijn. 


Met de eigenschappen van momentane afhankelijkheid genoemd in de lemma’s 2.7 tot 
en met 2.10 corresponderen overeenkomstige eigenschappen van permanente 
afhankelijkheid. Formuleer (en bewijs) die eigenschappen. 


2.46. (a) Gain Voorbeeld 2.8 na dat {NR} > (NR, ADR, WPL} in WP, 


(ADR, WPL} 5 {PC} in WP en (ADR, PC} 5 {WPL} in WP. 
(b) Is {NR} permanent afhankelijk van {NM, ADR, WPL} in WP? 
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2.47. Figuur 2.9 representeert twee tabellen; zij T6 de tabel gerepresenteerd in (a) en T7 de 
tabel gerepresenteerd in (b). We definiëren W1 = {T1, T6, T7} en W2 = W1 U {Ø}, 
waarbij T1 de tabel uit Voorbeeld 2.5 is. Bepaal alle permanente afhankelijkheden in 


W1 respectievelijk W2 die van de vorm B 5 {c} zijn, waarbij c € 
SAL, GESL, AFDNR} — B en B minimaal is in de volgende zin: 
VB’ cB: als B’ {c} in W1 (respectievelijk W2) dan B’ =B. 


(a) 
(b) 


(c) 


pe [Nw [on Toes [aro 


JANSSEN 

HEKKING 
HEKKING 
DEKKER 


(a) De tabel T6 


ve [NAAM sar [ est ] arne 
JANSSEN | 2452 
EET 


(b) De tabel T7 


Figuur 2.9 


2.48. Zij WP1 de verzameling van alle elementen T van de in Voorbeeld 2.8 gedefinieerde 
tabellenverzameling WP die voldoen aan de eis dat elk tweetal tupels in T met dezelfde 
postcode en hetzelfde huisnummer ook hetzelfde adres heeft. 


Geef een formele definitie van WP1. 


Heeft de zojuist omschreven eis de vorm van een permanente afhankelijkheid in 


Is WP1 een echte deelverzameling van WP? 
Licht uw antwoord toe. 
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2.2.2 Sleutels en minimale sleutels 


We noemen B een sleutel van een tabellenverzameling W als B uniek identificerend is in élk 
element van W. Als bovendien geen enkele echte deelverzameling van B een sleutel van W is 
dan noemen we B ook wel een minimale sleutel van W. Om precies te zijn: 


DEFINITIE 2.10: 
Als A een verzameling is en W is een verzameling tabellen over A, dan: 
B is een sleutel van W B is een verzameling en 

VT e W: Bis wi. in T. 


DEFINITIE 2.11: 
Als A een verzameling is en W is een verzameling tabellen over A, dan: 
B is een minimale sleutel van W <>B is een sleutel van W en 
VB’ CB : B’ is geen sleutel van W. 


We willen er op wijzen dat in de (Nederlandstalige) literatuur de term sleutel ook wel wordt 
gebruikt in de zin van Definitie 2.11. In de Engelstalige literatuur wordt de overeenkomstige 
term key ook in beide betekenissen gebruikt, terwijl de term superkey uitsluitend in de zin 
van Definitie 2.10 voorkomt. 


VOORBEELD 2.10: 
De verzamelingen {NR, NAAM} en {NR} zijn voorbeelden van sleutels van de tabel- 
lenverzameling WM uit Voorbeeld 1.3; hieruit volgt overigens meteen dat {NR, 
NAAM] geen minimale sleutel van WM is. Omdat @ geen sleutel van WM is, is de 
sleutel {NR} van WM wél minimaal. 


De tabellenverzameling WA uit Voorbeeld 1.3 heeft precies twee minimale sleutels, 
namelijk {ANR} en {NAAM}. 


O Voorbeeld 2.10. 


Voor tabellenverzamelingen is Lemma 2.17 het analogon van Lemma 2.12. 
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LEMMA 2.17: 


Als A een verzameling is en W is een verzameling tabellen over Aen B Aen C cA en 
D CA, dan: 


(a) B is een sleutel van W desda B 5 A in W; 

(b) Bis een sleutel van W desda Va € A —B:B 5 {a} in W; 

(c) A is een sleutel van W; 

(d) als B een sleutel van W is en B c C, dan is C ook een sleutel van W; 

(e) als B een sleutel van W is en C 5 B in W, dan is C ook een sleutel van W; 
(BD) alsB >CinWenD (A-C)in W, danis B U D een sleutel van W; 
(g) Øis een sleutel van W desda VTe W:ITI<1. 


We besluiten §2.2.2 met de invoering van enige additionele begrippen en notaties aangaande 
minimale sleutels van tabellenverzamelingen. Laat W een verzameling tabellen over een ver- 
zameling A zijn. We beginnen met de opmerking dat, op een paar uitzonderlijke gevallen 
van W na, de verzameling A is uit te drukken in termen van W: A = He( U W); zie Opgave 
2.56. We zullen He( U W) daarom de heading van W noemen en aanduiden met Head(W). 
Verder duiden we de verzameling van alle minimale sleutels van W aan met Ms(W): 


DEFINITIE 2.12: 
Als A een verzameling is en W is een verzameling tabellen over A, dan: 


(a) Head(W) = He( U W); 
(b) Ms(W) (B < Head(W) | B is een minimale sleutel van W}. 


Is WS 


Een element van Head(W) noemen we een attribuut van W. Een element van een minimale 
sleutel van W noemen we wel een primair attribuut van W; de andere attributen van W noe- 
men we secundair. De verzameling van alle primaire attributen van W duiden we aan met 
Prim(W) en de verzameling van alle secundaire attributen van W met Sec(W): 


DEFINITIE 2.13: 

Als A een verzameling is en W is een verzameling tabellen over A, dan: 
(a) PrimWw) = U Msc); 

(b) Sec(W) = Head(W) — Prim(W). 
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VOORBEELD 2.11: 
In Opgave 2.49 wordt gevraagd te bewijzen dat 


Ms(WA) = {{ANR}, {NAAM}} en Ms(WM) = {{NR}}. 


Met behulp van Definitie 2.13 (en Lemma 0.1) kunnen we hieruit vervolgens de 
verzamelingen primaire attributen van WM en WA berekenen: 


Prim(WM) = LU Ms(WM) = U {{NR}} = {NR} en 
Prim(WA) =U Ms(WA) = U {{ANR}, {NAAM}} 
= {ANR} U {NAAM} = {ANR, NAAM}. 


O Voorbeeld 2.11. 


OPGAVEN 


2.49. Bewijs dat de attributenverzamelingen {ANR} en {NAAM} van WA en {NR} van 
WM de enige minimale sleutels van die tabellenverzamelingen uit Voorbeeld 1.3 zijn. 


2.50. Bewijs Lemma 2.17. 
2.51. Formuleer en bewijs een analogon van Lemma 2.13 voor tabellenverzamelingen. 


2.52. (a) Bepaal de verzameling van alle minimale sleutels van WP uit Voorbeeld 2.8. 
(b) Bepaal de verzameling van alle minimale sleutels van W1 uit Opgave 2.47. 


2.53. Als A een verzameling is en W is een verzameling tabellen over A en B’ c A en B CB’ 
en B is een minimale sleutel van W en W’ c W en A is een injectieve functie op B, is 


dan: 
(a) Beenminimale sleutel van W’? 
(b) Been minimale sleutel van {T | B’ | Te W}? 


(c) dom(h) een minimale sleutel van {T œ h | Te W}? 


Geef telkens een bewijs of een tegenvoorbeeld. 
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2.54. Bewijs dat elke eindige sleutel van een tabellenverzameling W een minimale sleutel 
van W omvat. 


2.55. Toon met behulp van een voorbeeld aan dat niet elke (oneindige) sleutel een minimale 
sleutel omvat. 


2.56. (a) Voor welke tabellenverzamelingen W over een verzameling A is A eenduidig 
door W bepaald? 


(b) Bewijs dat in dat geval A = He(l) W). 
(c) Bereken Hel W) in de andere gevallen. 


2.2.3 Enige normaalvormen 


Voor tabellenverzamelingen worden er in de literatuur diverse zogenaamde "normaalvor- 
men" onderscheiden. We zullen in deze paragraaf alleen de twee belangrijkste normaalvor- 
men behandelen, namelijk de Boyce-Codd normaalvorm (afkorting: BCNF) en de derde 
normaalvorm (afkorting: 3NF). 


We definiëren eerst wanneer een tabellenverzameling in Boyce-Codd normaalvorm is: 


DEFINITIE 2.14: | 

Als A een verzameling is en W is een verzameling tabellen over A, dan: 

Wisin BCNF <>VB c Head(W) : Va e Head(W): als B > {a} in Wena ¢ B 
dan is B een sleutel van W. 


In de literatuur wordt voor BCNF en voor 3NF ook nog geëist dat de tabellenverzameling in 
INF (eerste normaalvorm) is, dat wil zeggen dat elke attribuutwaarde “atomair” is. Het 
begrip "atomair" wordt dan meestal omschreven als “nondecomposable by the underlying 
database management system", zie bijvoorbeeld [Ya 86]. (Als kritische kanttekening merken 
we hierbij op dat een DBMS bijvoorbeeld meestal in staat is om strings te decomponeren in 
substrings . . . Is het DBMS nu te krachtig of zijn strings niet als attribuutwaarden toege- 
staan?) 


We laten de (nogal vage) INF-eis bij al onze normaalvormen weg, niet alleen bij BCNF en 
3NF maar later ook bij de definitie van 2NF en 4NF (in de herhalingsopgaven aan het eind 
van Hoofdstuk 2). De reden daarvoor is niet alleen dat deze eis in feite niet goed 
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formaliseerbaar is, maar vooral ook dat deze (DBMS-afhankelijke) eis naar onze mening niet 
op dit niveau thuishoort. Daar komt nog bij dat "non-1NF databases" in diverse toepassingen 
vaak wenselijk zijn. Dit besef schijnt ook elders door te dringen, zie bijvoorbeeld [RKS 88]. 


De oorspronkelijke definitie van 3NF is te vinden in [Co 72] en van BCNF in [Co 74]. 
We geven nu onze definitie van 3NF: 


DEFINITIE 2.15: 

Als A een verzameling is en W is een verzameling tabellen over A, dan: 

Wisin 3NF <>VB c Head(W) : Va e Sec(W): als B 5 {a} inWena¢ B 
dan is B een sleutel van W. 


Informeel kunnen we de twee normaalvormen als volgt onder woorden brengen: W is in 
BCNF als elke attributenverzameling B die een attribuut buiten B "bepaalt" een sleutel is, en 
W is in 3NF als elke attributenverzameling B die een secundair attribuut buiten B "bepaalt" 
een sleutel is. BCNF is dus een sterkere eigenschap dan 3NF: 


LEMMA 2.18: 


Als A een verzameling is en W is een verzameling tabellen over A, dan: 
Als W in BCNF is, dan is W ook in 3NF. 


VOORBEELD 2.12: 
We geven een voorbeeld van een tabellenverzameling die wél in 3NF maar niet in 
BCNF is. We laten ons daartoe inspireren door de structuur van het postcodeboek. (We 
nemen hierbij uit Voorbeeld 2.8 de hulpfunctie F2 over.) 


F2 = {(NR ; [1000 .. 99997), nummer van de postcode 
(LC 3; Chs (2) 55 letters van de postcode 
FPCB = {(STR ; Chs(50)), straat 
(HNR; Chs(6)), huisnummer 
(WPL; Chs(40)), woonplaats 
(PC ;H(F2))}; postcode 


WPCB = {T | T c II(FPCB) en 
(STR, HNR, WPL} is u.i. in T en 
{PC, HNR} is u.i. in T en 
{PC} — {WPL} in T} 
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We merken op dat Ms(WPCB) = {{STR, HNR, WPL}, (PC, HNR}}, zodat dus alle 
attributen van WPCB primaire attributen zijn. Hieruit volgt dan op triviale wijze dat 
WPCB in 3NF is. Dat WPCB niet in BCNF is volgt uit het feit dat {PC} 5 {WPL} in 
WPCB, terwijl {PC} geen sleutel van WPCB is. 


O Voorbeeld 2.12. 


OPGAVEN 


2.57. Ga voor de volgende tabellenverzamelingen na of deze in BCNF zijn. 
(a) WP uit Voorbeeld 2.8; 
(b) WPI uit Opgave 2.48; 
(c) W1 uit Opgave 2.47; 
(d) W2 uit Opgave 2.47; 
(e) {Ø}; 
(f) Ø. 


2.58. Als W een tabellenverzameling over een verzameling A is en C c A en W’ c W en Wis 
in BCNF, zijn dan ook W’ en {T | C | T e W} in BCNF? 
Als W’ in BCNF is, is dan ook W in BCNF? 


2.59. Bewijs dat Ms(WPCB) in Voorbeeld 2.12 inderdaad gelijk is aan {{STR, HNR, WPL}, 
{PC, HNR} }. 


2.60. Geef het bewijs van Lemma 2.18. 
2.61. Ga voor de tabellenverzamelingen uit Opgave 2.57 na of deze in 3NF zijn. 


2.62. Als W een tabellenverzameling over een verzameling A is en C c A en W’ c W en Wis 
in 3NF, zijn dan ook W’ en {T | C | T e W} in 3NF? 
Als W’ in 3NF is, is dan ook W in 3NF? 


64 ENIGE CENTRALE DATABASE-BEGRIPPEN 


2.3 BEGRIPPEN BETREFFENDE DATABASE-UNIVERSA 


In §2.3.1 beginnen we met de behandeling van de eigenschappen van enige operaties op 
DB-universa. 


De in §2.2 ingevoerde begrippen permanente afhankelijkheid en (minimale) sleutel willen 
we ook gebruiken op het niveau van DB-universa. De precieze terminologie en de 
bijbehorende notaties worden geintroduceerd in §2.3.2. 


In §2.3.3 zullen we de in §2.2.3 gedefinieerde normaalvormen voor tabellenverzamelingen 
generaliseren tot normaalvormen voor DB-universa. In feite gaat het ons namelijk niet 
zozeer om normaalvormen voor een "losse" tabellenverzameling maar meer om normaalvor- 
-= men voor een DB-universum als geheel. 


In $2.3.4 openen we met een generalisatie van het in §2.1.4 ingevoerde verbindingsbegrip. 
Verder definiëren we in deze paragraaf het conceptueel belangrijke begrip database-functie. 


Tot nu toe hebben we slechts één voorbeeld van een DB-universum laten zien, te weten het 
DB-universum VBU in Voorbeeld 1.3. Voordat we de afzonderlijke begrippen betreffende 
DB-universa behandelen, willen we daarom eerst nóg een voorbeeld van een DB-universum 
geven. 


VOORBEELD 2.13: 

We herhalen de "modules" F1, F2, F3, F4 en WP uit Voorbeeld 2.8 en breiden dit 
voorbeeld uit tot een DB-universum U1 (betreffende personen en gemeenten in Neder- 
land). We doen dit door toevoeging van een deelverzameling S2 van Chs(2), een 
objectkarakterisering F5, een tabellenverzameling WG, een database-karakterisering 
F6 en tenslotte het DB-universum U1. (We merken overigens op dat deze structuur 
strict genomen niet precies de Nederlandse situatie weerspiegelt, onder andere omdat 
we (eenvoudigheidshalve) woonplaatsen en gemeenten met elkaar hebben 
geïdentificeerd. Ook hoeft een gemeentenaam niet uniek te zijn. In Opgave 2.105 
komen we hierop terug.) 
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F1 = {(STR ; Chs(50)), F4= {(NR_ ; N-{0}), 
(HNR ; [1 .. 5000])}; (NM ; Chs(40)), 
(ADR ; II(F1)), 
F2= {(NR_ ; [1000 … 9999}), (PC ;II(F2)), 
(LC ;Chs(2))}; (WPL ; Chs(30)), 
(GBD ; II(F3)), 
F3= {(DG ;[1..31)), (GPL ; Chs(30)), 
(MND; [1 .. 12]), (NMK; P(Chs(30)))}; 
OR ; AND}; 


WP = {T cII(F4) | {NR} is wi. in T en 
{PC} — {WPL} in T en 
(ADR, WPL} — {PC} in T en 
Vt e T: als (NR) # 1 dan Jt’ € T : (NR) = (NR) — 1}; 


SES OR, PR, IDR OV, de provincies van Nederland 
FL’ ‘GE’ TT’ ‘NH’ 
‘7H’ ‘ZE’ ‘NB’ "P E 


F5= {(WPL ; Chs(30)), gemeentenaam 
(PROV ; S2), provincie 
(INWA; N), inwoneraantal 
(OPVL; N), oppervlakte (in hectare) 
(NR; AN}; identiteitsnummer van de burgemeester 


WG = {T c II(F5) | {WPL} is u.i. in T}; 


F6 = {(PERS ; WP), 


(GEM ; WG)}; 
U1 = {v e II(F6) | id({ WPL}) verbindt v(PERS) met v(GEM) en (a) 
id({ NR, WPL}) verbindt v(GEM) met v(PERS)} (b) 


O Voorbeeld 2.13. 
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2.3.1 Operaties op database-universa 


In deze paragraaf zijn we geinteresseerd in operaties die aan een of meer DB-universa weer 
een DB-universum toevoegen. 


Omdat een DB-universum een verzameling is, zijn begrippen als deelverzameling, vereni- 
ging, doorsnede en verschil ook van toepassing op DB-universa. Dergelijke operaties leveren 
meestal ook weer DB-universa op, en wel over het oorspronkelijke DB-skelet, zie (1), (2) en 
(3) van Stelling 2.1 voor de details. 


We roepen verder ook nog Stelling 1.1 in herinnering die zegt dat elk DB-universum over 
een verzamelingsfunctie g tevens een tabel over dom(g) is. Dat betekent dus dat alle begrip- 
pen, notaties en operaties die we intussen voor tabellen hebben gedefinieerd eveneens op 
DB-universa van toepassing zijn! 


In het bijzonder kunnen we dus de in §2.1.1 ingevoerde tabeloperaties ook op DB-universa 
toepassen; die operaties leveren volgens de resultaten in die paragraaf telkens weer tabellen 
op. De vraag is echter of het toepassen van zo’n operatie op DB-universa ook weer een DB- 
universum oplevert, en zo ja, over welk DB-skelet. Vanaf onderdeel (4) gaat Stelling 2.1 ook 
op deze vraag in en levert daarbij een aantal interessante resultaten op. We zullen echter 
eerst kort omschrijven waar die operaties uit $2.1.1 voor DB-universa op neerkomen: 


— Projectie (op een verzameling tabelindexen) correspondeert met het beperken van het 
DB-universum (en van de DB-toestanden) tot een "module" of "subschema" van (al 
dan niet “bij elkaar behorende") tabelindexen. 


— De join van twee DB-universa met compatibele DB-skeletten correspondeert met het 
“integreren” van alle mogelijke paren DB-toestanden die voor gelijknamige tabelin- 
dexen dezelfde (tabel)waarde hebben, tot een DB-toestand die alle tabelindexen van de 
oorspronkelijke twee DB-toestanden bevat. 


—  Herbenoeming, tenslotte, komt bij DB-universa neer op het herbenoemen van tabelin- 
dexen. 


Met de nummering binnen Stelling 2.1 volgen we (tot en met (6)) de nummering van de 
lemma's in §2.1.1 over diezelfde operaties. 
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STELLING 2.1: 

Als g en g’ verzamelingsfuncties zijn 

en U en V zijn DB-universa over g 

en U’ is een DB-universum over g’ 

en D c U en X c dom(g) en h is een functie, dan: 


(H-D is een DB-universum over g; 
E CONV is een DB-universum over g en 
U-V is een DB-universum over g; 
Oe. Uy is een DB-universum over g; 
W UTX is een DB-universum over g | X; 
(5) UpaqU’ iseen DB-universum over g U g’ mits g en g’ compatibel zijn; 
(6) Uœæh is een DB-universum over g o h; 
(7) UX is een DB-universum over g+ X. 
Bewijs: 
(1) Elk element van U is een DB-toestand over g, dus elk element van D is dat ook. 
(2) Dit volgt direct uit (1). 
(3) Elk element van U is een DB-toestand over g en 
elk element van V is een DB-toestand over g, 
dus elk element van U U V is dat ook. 
(4) In dit onderdeel maken we (stilzwijgend) intensief gebruik van Lemma 0.11: 
Elk element van U | X is van de vorm v | X, waarbij v e U. 
Nu geldt dat dom(v} X) =X = dom(g | X), dus v | X is een functie over dom(g} X). 
Verder geldt voor elke E e dom(g} X) dat (v | X) (E) = v(E), 
dus (wl X) (E) is een tabel over g(E), ofwel over (g{ X) (E). 
Volgens Definitie 1.2 is v | X dus een DB-toestand over g } X. 
Volgens Definitie 1.3 is U | X dus een DB-universum over g | X. 
(5) In dit onderdeel maken we gebruik van Lemma 0.2(b): 


Elk element van U pq U’ is van de vorm v U v’, 

waarbij v e U en v’ e U’ env U v’ een functie is. 

Nu geldt dat dom(v U v^) = dom(v) U dom(v’) = dom(g) U dom(g’) = dom(g U g’), 
dus v U v’ is een functie over dom(g U g’). 

Verder geldt voor elke E e dom(g U g’) dat 
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— Ee dom(v), zodat (v U v’) (E) = v(E), een tabel over g(E), of 

— Ee dom(v’), zodat (v U v’) (E) =v'(E), een tabel over g'(E). 

Omdat g en g’ compatibel zijn, is dus (vU v’) (E) in beide gevallen een tabel over 
(g Y g’) (E). 

Volgens Definitie 1.2 is v U v’ dus een DB-toestand over g U g’. 

Volgens Definitie 1.3 is U >< U’ dus een DB-universum over g U g’. 


(6) Elk element van U ee his van de vorm v o h, waarbij v e U. 
Omdat dom(v) = dom(g), geldt volgens Lemma 0.9(g) dat dom(v o h) = dom(g o h); 
dus v o his een functie over dom(g o h). 
Verder geldt voor elke E e dom(g h) dat (v o h) (E) = v(h(E)), 
dit is een tabel over g(h(E)), ofwel over (g o h) (E). 
Volgens Definitie 1.2 is v o h dus een DB-toestand over g o h. 
Volgens Definitie 1.3 is U oo h dus een DB-universum over g o h. 


(7) Het bewijs van dit onderdeel is analoog aan dat van (4). 
(Voor de definitie van U # X verwijzen we naar Opgave 2.22.) 


O 


In de opgaven behorende bij §2.1.1 worden nog diverse eigenschappen opgesomd van de in 
Stelling 2.1 behandelde operaties bij toepassing op tabellen. Deze eigenschappen gelden dus 
evenzeer bij toepassing op DB-universa! 


OPGAVEN 


2.63. Schrijf het DB-skelet uit van het DB-universum U1 dat in Voorbeeld 2.13 is 
gedefinieerd. 


_ 2.64. Geef een informele omschrijving van de formele eisen (a) en (b) in de definitie van U1. 
2.65. Geef een element van U1, bijvoorbeeld met behulp van de tabel TP in Figuur 2.7. 


2.66. Is in elke DB-toestand conform U1 het inwoneraantal van een gemeente in overeen- 
stemming met het aantal personen met die gemeente als woonplaats? 
Zo ja, toon dit dan aan; zo nee, geef dan een formele definitie van het DB-universum 
U2 bestaande uit alle elementen van U1 die wél die eigenschap hebben. 


2.67. Ga na in hoeverre de lemma’s 2.4, 2.5 en 2.6 nog aangescherpt of verfijnd kunnen wor- 
den voor DB-universa. Licht uw bevindingen toe. 
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2.3.2 Permanente afhankelijkheid en (minimale) sleutels 


We definiéren de begrippen permanente afhankelijkheid, sleutel en minimale sleutel met 
betrekking tot een tabelindex E van een DB-universum U door de overeenkomstige 
begrippen uit 82.2 toe te passen op de tabellenverzameling {v(Z) | ve U}. We zullen deze 
tabellenverzameling het universum van E in U noemen en aanduiden met Un(E, U). 


DEFINITIE 2.16: 
Als g een verzamelingsfunctie is en U is een DB-universum over g en E € He(U), dan: 
Un(E,U) = {v(E) l ve U}. 


DEFINITIE 2.17: 

Als g een verzamelingsfunctie is en U is een DB-universum over g en E e He(U) en B en C 
zijn verzamelingen, dan: 

B SCinEvanU &>B Cin Un(E,U). 


DEFINITIE 2.18: 
Als g een verzamelingsfunctie is en U is een DB-universum over g en E € He(U), dan: 
(a) B is een sleutel van E in U <>B is een sleutel van Un(E, U); 


(b) B is een minimale sleutel van E in U B is een minimale sleutel van Un(E,U). 


Op analoge wijze tillen we de in de Definities 2.12 en 2.13 ingevoerde notaties betreffende 
een tabellenverzameling W naar het niveau van een tabelindex E van een DB-universum U. 
De nieuwe notaties zijn te onderscheiden van de gelijknamige oude notaties doordat ze twee 
parameters hebben in plaats van één. 


DEFINITIE 2.19: 

Als g een verzamelingsfunctie is en U is een DB-universum over g en E e He(U), dan: 
(a) Head(E,U) = Head(Un(E, U); 

(b) Ms(E,U) = Ms(Un(E,U)); 

(c) Prim(E,U) 2 Prim(Un(E,U)); 

(d) Sec(E,U) 2 Sec(Un(E,U)). 


We zullen de voorgaande begrippen toelichten aan de hand van het in Voorbeeld 2.13 
gedefinieerde DB-universum U1. 
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VOORBEELD 2.14: 
We zullen eerst de verzamelingen Un(PERS, U1) en Un(GEM, U1), de universa van de 
tabelindexen PERS en GEM in U1, proberen te bepalen. Uit de definities van U1 en F6 
volgt meteen dat 


Un(PERS, UI) c WP en Un(GEM, UI) c WG. 


Of deze inclusies ook gelijkheden zijn, is echter minder eenvoudig in te zien. We 
tonen eerst aan dat elke T e WP inderdaad kan optreden als PERS-tabel in een 


geschikt gekozen vr e U1. We definiëren daartoe de functie vr over (PERS, GEM} als 
volgt: 


vr (PERS) =T en 


vr (GEM) = (((WPL ; t(WPL)), 
(PROV; ‘GR’), 
(INWA; 20000), 
(OPVL ; 6000), 
(NR _ ; ¢(NR))} 
| te Ten Vt’ e T: als (WPL) = t’(WPL) dan t(NR)§ t’(NR)} (c) 


De functie vr blijkt een element van U1 te zijn (zie Opgave 2.68(b)). Hiermee hebben 
we dan dus aangetoond dat WP c Un(PERS, U1), en derhalve dat Un(PERS, U1) in 
feite gelijk is aan WP. (Dat zo’n DB-toestand vy misschien niet erg realistisch aandoet, 
is natuurlijk in dit verband niet relevant.) 


We laten nu zien dat het universum van GEM in U1 een echte deelverzameling van 
WG is. We zullen zelfs iets meer bewijzen, namelijk dat 


Un(GEM, UI) < {T e WG | {NR} is u.i. in T}. (0) 


Gemakshalve zullen we {T e WG | {NR} is u.i. in T} in het vervolg WG2 noemen. 
Aangezien WG2 een echte deelverzameling van WG is (zie ook Opgave 2.69(a)), is 
Un(GEM, U1) dat dus ook. (In feite blijkt Un(GEM, U1) zelfs ook een echte deelver- 
zameling van WG2 te zijn, zie Opgave 2.69(b). Sterker nog, het is zelfs vrij moeilijk 
om Un(GEM, U1) expliciet als deelverzameling van WG te karakteriseren, zie Opgave 
Z 13.) 


Om bovenstaande inclusie aan te tonen moeten we dus bewijzen dat 


BEGRIPPEN BETREFFENDE DATABASE-UNIVERSA 71 
Vve U1: {NR} is u.i. in v(GEM). 
Stel daarom dat v e U1, t e v(GEM), t’ e v(GEM) en (NR) = (NR); (1) 


we moeten dus bewijzen dat t = t’, aldus de definitie van unieke identificatie. 
Dankzij eis (b) in de definitie van U1 bestaan er tupels p en p’ in v(PERS) waarvoor 


geldt: 

(NR) = p(NR) en (NR) = p’(NR) en (2) 
t(WPL) = p(WPL) en t’(WPL) = p’(WPL). (3) 
Uit (1) en (2) volgt nu dat p(NR) = p’(NR). (4) 


Aangezien v(PERS) e WP, is {NR} u.i. in v(PERS) volgens de definitie van WP. (5) 
Uit (4) en (5) volgt nu dat p =p’. 

Met behulp van (3) kunnen we nu concluderen dat t(WPL) = t’(WPL). (6) 
Aangezien v(GEM) e WG, is {WPL} u.i. in v(GEM). 

Uit (6) volgt daarom dat t = 2’. 


Hiermee hebben we (0) bewezen. In feite blijkt dus {NR} een sleutel van GEM in U1 
te zijn hoewel {NR} geen sleutel is van de tabellenverzameling WG die tijdens de 
definitie van U1 is gebruikt! Dergelijke neveneffecten van de andere voorwaarden die 
gesteld zijn treden overigens in de praktijk wel vaker op (en ook zonder dat men zich 
daarvan altijd meteen bewust is). 


Na dit voorbereidende werk kunnen we nu de berekening van de "kernverzamelingen" 
Ms(PERS, U1) en Ms(GEM, U1) aan de lezer overlaten; zie Opgave 2.71. 


Ter illustratie van Definitie 2.17 besluiten we dit enigszins uitvoerige voorbeeld met de 
simpele constatering dat bijvoorbeeld (ADR, WPL} 5 {PC} in PERS van U1, dit 
omdat (ADR, WPL} 5 {PC} in WP en Un(PERS, U1) = WP. 


O Voorbeeld 2.14. 
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Bij gegeven DB-skelet blijven permanente afhankelijkheden en sleutels behouden onder 
“inkrimping” van het DB-universum: 


LEMMA 2.19: 

Als g een verzamelingsfunctie is en U en U’ zijn DB-universa over g en E e dom(g) en B en 
C zijn verzamelingen, dan: 

(a) Als U’ c U en B C in E van U, dan B -> C in E van U’. 

(b) Als U’ c U en B is een sleutel van E in U, dan is B ook een sleutel van E in U’. 


Het bewijs van dit eenvoudige lemma laten we in de opgaven aan de lezer over. Ook gaan 
we daar in op de vraag in hoeverre dit lemma nog kan worden uitgebreid. 


OPGAVEN 

2.68. In deze opgave gaan we in op de functie vr over (PERS, GEM} die in Voorbeeld 2.14 
is gedefinieerd. 
(a) Geef een informele omschrijving van de formele eis (c) in de definitie van vr. 


(b) Bewijs dat voor elke T e WP de functie vr inderdaad een element van U1 is. 


2.69. Uit de definitie van WG2 in Voorbeeld 2.14 volgt direct dat WG2 c WG. 
In Voorbeeld 2.14 werd verder ook bewezen dat Un(GEM, U1) c WG2. 


(a) Bewijs nu dat WG2 c WG. 
(b) Bewijs ook dat Un(GEM, U1) c WG2. 


2.70. Ga na welke van de volgende permanente afhankelijkheden er in Voorbeeld 2.13 gel- 
den en licht uw antwoord telkens kort toe. 


(a) {NR} 5 {WPL} in PERS van U1; 
(b) {NR} 5 {WPL} in GEM van U1; 
(c) {WPL} 5 {NR} in PERS van U1; 
(d) {WPL} 5 {NR} in GEM van U1. 


2.71. In deze opgave gaan we nader in op de minimale sleutels van de in de voorbeelden 
2.13 en 2.14 gedefinieerde verzamelingen. 
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belde 


2 EN 


2.74. 


2:13: 


2.76. 


(a) Bepaal Ms(WG) en Ms(WG2). 
(b) Bepaal Ms(PERS, U1) en Ms(GEM, U1). 


Bepaal Ms(MEDEW, VBU) en Ms(AFD, VBU), waarbij VBU het in Voorbeeld 1.3 
geïntroduceerde DB-universum is. 


In Opgave 2.69 hebben we geconstateerd dat 

Un(GEM, UI) c WG, ja zelfs dat 

Un(GEM, UI) c {T e WG | {NR} is u.i. in T}. 

(a) Probeer Un(GEM, U1) expliciet als deelverzameling van WG te karakteriseren, 
of althans zo dicht mogelijk "van boven af" te benaderen, dat wil zeggen probeer 
een zo sterk mogelijke voorwaarde (7) te geven (waarin Un(GEM, UI) zelf niet 
genoemd wordt) zodanig dat Un(GEM, UI) < {T e WG | ò(T)} of zelfs zodanig 
dat Un(GEM, UI) = {T e WG | ò(T)}. 


(b) Bewijs de door u onder (a) gegeven inclusie, c.q. gelijkheid. 
Bewijs Lemma 2.19. 


Blijven bij gegeven DB-skelet behalve de permanente afhankelijkheden en de sleutels 
ook de minimale sleutels behouden onder inkrimping van het DB-universum? 
Geef een bewijs of een tegenvoorbeeld. 


Ga na of permanente afhankelijkheden en sleutels ook behouden blijven onder de 
andere in Stelling 2.1 genoemde operaties op DB-universa. 


. Ga na in hoeverre ook minimale sleutels behouden blijven onder de andere in Stelling 


2.1 genoemde operaties op DB-universa. 


2.3.3 Enige normaalvormen voor database-universa 


Een DB-universum U is in Boyce-Codd normaalvorm (respectievelijk derde normaalvorm) 
als Un(E,U) voor elke tabelindex E van U in BCNF (respectievelijk 3NF) is. Ter onder- 
scheiding van de normaalvormen voor tabellenverzamelingen zullen we voor de normaalvor- 
men voor DB-universa de Nederlandse afkortingen gebruiken: 
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DEFINITIE 2.20: 
Als g een verzamelingsfunctie is en U is een DB-universum over g, dan: 


(a) UisinBCNV <>VE e He(U) : Un(E,U) is in BCNF: 
(b) Uisin3NV < VE e He(U) : Un(E,U) is in 3NF. 


Lemma 2.20 is een direct gevolg van Lemma 2.18 (omdat we Lemma 2.18 kunnen toepassen 
op de tabellenverzameling Un(E,U)). 


LEMMA 2.20: 
Als g een verzamelingsfunctie is en U is een DB-universum over g, dan: 
Als U in BCNV is, dan is U ook in 3NV. 


OPGAVEN 


2.78. Is U1 van Voorbeeld 2.13 in BCNV of in 3NV? 


2.79. We definiéren (uitgaande van Voorbeeld 2.13): 
WP2 = {T cII(F4) | {NR} is u.i. in T}; 


F7 = {(PERS ; WP2), 
(GEM ; WG)}; 


U3 = {v e II(F7) | id({ WPL}) verbindt (PERS) met v(GEM) en 
id({NR, WPL}) verbindt (GEM) met v(PERS) en 
{(GPL; WPL)} verbindt v(PERS) met v(GEM)}. 


We wijzen er alvast op dat aan het eind van §2.4 al deze definities nog eens bij elkaar 
staan in een overzicht van alle definities betreffende onze personen/gemeenten- 
voorbeelden. 


(a) Geef de "nieuwe" eis in de definitie van U3 in woorden weer. 
(b) Is U3 in BCNV of in 3NV? 

(c) Zij Ul en U3 disjunct? Is de een bevat in de ander? 

(d) Bewijs dat II(F6) c II(F7). 
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2.80. Ga na in hoeverre BCNV behouden blijft onder de in Stelling 2.1 genoemde operaties 
op DB-universa. 


2.81. Werk voor 3NV hetzelfde programma af. 
O 


2.3.4 Permanente verbinding en database-functies 


We willen de in §2.1.4 gedefinieerde verbindingsbegrippen ook definiéren op het niveau van 
DB-universa. We doen dit als volgt: 


DEFINITIE 2.21: 
Als g een verzamelingsfunctie is en U is een DB-universum over g en M e He(U) en 
D e He(U) en A is een functie, dan: 


(a) h verbindt M permanent met D in U < Vy e U : h verbindt v(M) met v(D); 


(b) h verbindt M permanent bilateraal met D in U vv e U : h verbindt v(M) 
bilateraal met v(D). 


VOORBEELD 2.15: 
Uit de Voorbeelden 1.3 en 2.13 lezen we de volgende permanente verbindingen in 
VBU respectievelijk U1 af: 


{(AFDNR; ANR)} verbindt MEDEW permanent met AFD in VBU; 
{(MANNR; NR)} verbindt AFD permanent met MEDEW in VBU; 
id({NR, WPL}) verbindt GEM permanent met PERS in U1; 
id({ WPL}) verbindt PERS permanent met GEM in U1. 


Uit de laatste twee permanente verbindingen kunnen we zelfs een permanente bila- 
terale verbinding afleiden: 


id({ WPL}) verbindt GEM permanent bilateraal met PERS in U1. 
O Voorbeeld 2.15. 


Het volgende begrip leiden we weer in met een voorbeeld. 
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VOORBEELD 2.16: 
Uit de definitie van U1 in Voorbeeld 2.13 kan worden afgeleid dat er voor elke v in U1 
een functie H1(v) van v(PERS) naar v(GEM) bestaat die aan elk “persoonstupel” in de 
DB-toestand v het (eenduidig bepaalde) tupel van diens woonplaats toevoegt. We 
merken op dat hier in feite sprake is van een (functiewaardige) functie H1 over U1. H1 
is een voorbeeld van wat we noemen een database-functie over U1 met betrekking tot 
het geordende paar tabelindexen (PERS; GEM). 


O Voorbeeld 2.16. 


De algemene definitie van het begrip database-functie luidt als volgt: 


DEFINITIE 2.22: 
Als g een verzamelingsfunctie is en U is een DB-universum over g en 
(M; D)e He(U) x He(U), dan: 
H is een DB-functie over U m.b.t. (M ; D) <>H is een functie over U en 
Vve U:H(v)e v(M)— v(D). 


We noemen M wel de bronindex van H en D wel de doelindex van H. 


Het volgende lemma geeft een in de praktijk belangrijke klasse van DB-functies en berust op 
Lemma 2.16. Het lemma zegt dat als een functie h de tabelindex M in een DB-universum U 
permanent verbindt met een tabelindex D, en mg(h) bovendien een sleutel van D in U is, dan 
is de functie die aan elke v e U de door h geïnduceerde associatie op v(M) x v(D) toevoegt 
een DB-functie over U met betrekking tot het paar (M ; D). 


LEMMA 2.21: 

Als g een verzamelingsfunctie is en U is een DB-universum over g en Me He(U) en 
D e He(U) en h is een functie en 

(1) mg(h) is een sleutel van D in U en 

(2) h verbindt M permanent met D in U, 

dan is Ave U : ((t;t)e v(M) x v(D) | t] dom(h) =t’ o h} een DB-functie over U met 
betrekking tot (M ; D). 


Bewijs: 

We gaan controleren of de bovengenoemde functie 

Ave U: {(t;t) e v(M)x v(D) | t| dom(h) = t’ o h} voldoet aan Definitie 2.22. 
Tijdens dit bewijs zullen we deze functie H noemen. 

Uit de definitie van H is het meteen duidelijk dat H een functie over U is. 
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Zij nu v e U. Het is duidelijk dat H(v) c v(M) x v(D). (a) 
Uit (1) volgt dat mg(A) u.i. in v(D) is. 

Volgens Lemma 2.16 (3) geldt nu dat H(v) een functie is. (b) 
Verder volgt uit (2) dat h de tabel v(M) met de tabel v(D) verbindt. 

Volgens Lemma 2.16 (1) geldt nu dat dom(H(v)) = v(M). (c) 


Uit (a), (b) en (c) volgt nu dat H(v) e v(M) — v(D) voor elke v e U. 
Dus H voldoet aan Definitie 2.22. 


O 


Lemma 2.22 geeft aan hoe we met behulp van gegeneraliseerde compositie uit twee gegeven 
DB-functies een "nieuwe" DB-functie kunnen verkrijgen. Gegeneraliseerde compositie 
definiéren we voor elk tweetal functiewaardige functies als volgt: 


DEFINITIE 2.23: 
Als G en H functiewaardige functies zijn, dan: 
GOH 2 Axe dom(G) A dom(H) : G(x) © H(x). 


Met andere woorden G © H, de gegeneraliseerde compositie van G na H, is de 
functie over dom(G) ^ dom(H) gedefinieerd door (G © H) (x) =G(x) o H(x) voor elke 
xe dom(G) ^ dom(H). We zullen gegeneraliseerde compositie vooralsnog alleen 
gebruiken indien dom(G) = dom(H) = U waarbij U een of ander DB-universum is. Zo ook in 
het volgende lemma dat zegt dat de gegeneraliseerde compositie van twee DB-functies met 
een corresponderende bron- en doelindex weer een DB-functie is: 


LEMMA 2.22: 

Als U een DB-universum over een verzamelingsfunctie g is en {M,D,D’} c He(U) en 
(1) His een DB-functie over U m.b.t. (M ; D) en 

(2) Gis een DB-functie over U m.b.t. (D;D’), 

dan is G © H een DB-functie over U m.b.t. (M; D^). 


OPGAVEN 


2.82. Verbindt ((GPL; WPL)} de tabelindex PERS permanent bilateraal met GEM in U3 
van Opgave 2.79? Geef een bewijs of een tegenvoorbeeld. 


2.83. (a) Geef een formele definitie van de in Voorbeeld 2.16 informeel omschreven func- 
tie H1. 
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2.84. 


2.85. 


2.86. 


2.87. 


2.88. 


2.89. 
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(b) Is H1 van de in Lemma 2.21 beschreven vorm? 


We definiëren de functies H2 en H3 als volgt: 


H2 = Àv e Ul: {(t;t’) e VGEM) x v(PERS) | (NR) = t’(NR)} en 
H3=Ave U1: {(t;t’) e PERS) x (GEM) | (GPL) = t’(WPL)}, 


waarbij U1 het in Voorbeeld 2.13 gedefinieerde DB-universum is. 
Geef een informele beschrijving van H2 en H3. Zijn H2 en H3 DB-functies? 
Zo nee, waarom niet? 


Bewijs het volgende: 

Als g een verzamelingsfunctie is en U is een DB-universum over g en 
M;D)e He(U) x He(U) en a e g(M) ena’ € g(D) en {a’} is een sleutel van D in U 
en {t(a) | te v(M)} c {t (a^) | t e v(D)} voor elke v e U, 

dan is Av e U: {(t;t’) e v(M)Xv(D) | t(a)=t'(a")} een DB-functie over U met 
betrekking tot (M; D). 

Als g een verzamelingsfunctie is en U een DB-universum over g en M e He(U) en 
D e He(U) en g(M) A g(D) is een sleutel van D in U en id(g(M) ^ g(D)) verbindt 
v(M) met v(D) voor elke v € U, en H is gedefinieerd door 


H =v € U: {(t;t’)€ v(M)Xv(D) | tenz’ stemmen overeen op g(M) AN g(D)}, 
dan: 

(a) His een DB-functie over U m.b.t. (M;D) en 

(b) v(M) >< v(D)= {t U H(v) (t) | te v(M)} voor elke v e U. 

Bewijs dit. 


Bewijs Lemma 2.22. 
Is gegeneraliseerde compositie associatief? 


Zijn H2 en H3 uit Opgave 2.84 functiewaardige functies? 
Zo ja, geef dan een informele beschrijving van: 


H2 © H1, H1 © H2, H2 © H3, H3 © H2 en H3 © (H2 © H1), 


waarbij H1 de in Voorbeeld 2.16 beschreven functie is. 
Welke hiervan zijn DB-functies over U1, en met betrekking tot welke indexparen? 
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2.90. 


2.9 


— 


2.92. 


We definiéren (uitgaande van Voorbeeld 2.13): 


WPE ={Te WPITiseindig}; 

WGE ={T e WGITis eindig}; 

F8 = {(PERS ; WPE), 
(GEM ; WGE)}. 


Deze definities staan ook in het overzicht aan het eind van §2.4, samen met de 
definities uit Voorbeeld 2.13. 


(a) Bewijs dat II(F8) c II(F6). 

(b) Bewijs dat WGE = WG. 

(c) Is WGE een eindige verzameling? 
(d) Bewijs dat WPE c WP. 


. Onder verwijzing naar de Opgaven 2.79, 2.84 en 2.90 (of het overzicht aan het eind 


van §2.4) definiëren we verder nog: 


U4 = U3 A II(F8), 
H4 = H2 | U4 en 
H5 = H3} U4. 


(a) Bewijs dat U4c UI. 
(b) Geef een informele beschrijving van H4 en H5. 
(c) Zijn H4 en H5 ook DB-functies? 


Uitgaande van Opgave 2.91 definiëren we (op recursieve wijze): 
Go = H4 © H5 en G,+1 =G, © Go voorelke ne IN. 


(a) Geef een informele beschrijving van Go. 
(b) Probeer voor willekeurige n e IN een informele beschrijving van G, te geven. 


(c) Bewijs dat voor elke n e IN de functie G, een DB-functie over U4 is. 
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(d) Bewijs dat voor elke v e U4 niet alle G,(v) verschillend zijn 
(m.a.w, Vve U4: Ane N:ime N:n#menG,(v)=G,()). 


(e) Ganaof alle G, verschillend zijn. 
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2.4 SAMENVATTING 


In Figuur 2.10 hebben we de in de hoofdstukken 1 en 2 ingevoerde begrippen bij elkaar 
gezet, gegroepeerd rondom de vier hoofdbegrippen tabel, tabellenverzameling, DB-toestand 
en DB-universum. De begrippen zijn op twee "orthogonale" manieren in tweeën verdeeld: 


(1) Enerzijds is er een scheidslijn tussen 


(a) die begrippen die in feite reeds behoren tot het gebied bestandstheorie 
(dat wil zeggen de theorie van afzonderlijke bestanden), en 


(b) die begrippen die pas een rol spelen bij database-theorie 
(dat wil zeggen de theorie van verschillende "geïntegreerde" bestanden). 


(2) Anderzijds is er een scheidslijn tussen 
(a) die begrippen die betrekking hebben op een toestand, en 
(b) die begrippen die betrekking hebben op een toestandsruimte. 


Dus, uitgaande van een tabel over een verzameling A kunnen we in twee "dimensies" uit- 
breiden: 


I: enerzijds naar verschillende soorten tabellen "tegelijkertijd" 
(dat wil zeggen naar een DB-toestand over een verzamelingsfunctie g), 
wat we bij de overgang van $1.1 naar $1.2 hebben gedaan, en 


II: anderzijds naar verschillende tabellen van dezelfde "soort" 
(dat willen zeggen naar een tabellenverzameling over A), 
wat we bij de overgang van $2.1 naar $2.2 hebben gedaan. 


Wanneer we in beide "dimensies" uitbreiden, dan komen we tot een DB-universum over g. In 
Hoofdstuk 1 hebben we dat bereikt door eerst uitbreiding I uit te voeren (van §1.1 naar §1.2) 
en daarna uitbreiding II (van §1.2 naar §1.3). Bij de opbouw van Hoofdstuk 2 daarentegen 
hebben we eerst uitbreiding II uitgevoerd (van §2.1 naar §2.2) en daarna uitbreiding I (van 
§2.2 naar $2.3). 
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Als een soort referentiekader geven we als laatste voorbeeld in dit hoofdstuk nog het simpele 
maar in de database-literatuur zeer bekende en veel gebruikte "suppliers/parts/shipments"- 
voorbeeld (zie onder andere [Da 86)). 


VOORBEELD 2.17: 


Het suppliers/parts/shipments-voorbeeld is gebaseerd op het volgende DB-skelet, dat 
we g2 zullen noemen: 


g2= {(S ; {S#, SNAME, STATUS, CITY}), suppliers 
(P ; {P#, PNAME, COLOR, WEIGHT, CITY}), | parts 
(SP; {S#, P#, QTY})} shipments 


Hierbij staat S# voor supplier number, P# voor part number en QTY voor quantity. 


We definiëren achtereenvolgens drie objectkarakteriseringen, één database- 
karakterisering en ten slotte het DB-universum. 


FS = {(S# ; Chs(5)), 
(SNAME ; Chs(20)), 
(STATUS; Int(4)), 
ELEN ERI}; 


FP = {(P# ; Chs(6)), 
(PNAME ; Chs(20)), 
(COLOR ; Chs(6)), 
(WEIGHT ; Int(4)), 
(CITY _ ; Chs(15))}; 


FSP = ((S# ;Chs(5)), 
(P# ; Chs(6)), 
(QTY; Int(9))}; 


SPSK = {(S_ ; {T CTIGS) | {S#} is u.i. in T}), 
(P ; {T c II(FP) | {P#} is u.i. in T}), 
(SP; {T c II(FSP) | {S#, P#} is u.i. in TH}; 
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SPSU = {v | v e II(SPSK) en 
{(S#; S#)} verbindt v(SP) met v(S) en 
{(P# ; P#)} verbindt v(SP) met v(P)}. 


We kunnen nu de volgende functies over SPSU definiéren: 


Shipsup =Ave SPSU: {(t; t’) € v(SP) x v(S) | t(S#) = t’ (S#)) 
Shippart = Av e SPSU: ((t; t) e v(SP) x v(P) | t(P#) = t (P#)} 


Volgens Lemma 2.21 is Shipsup een DB-functie over SPSU met betrekking tot het 
tabelindexpaar (SP; S) en Shippart een DB-functie over SPSU met betrekking tot het 
paar (SP; P). Voor v e SPSU is Shipsup(v) e v(SP) —® v(S) de functie die aan elk 
shipment-tupel in toestand v het "bijbehorende" supplier-tupel toevoegt en is 
Shippart(v) € v(SP) —® v(P) de functie die aan elk shipment-tupel in toestand v het 
“bijbehorende” part-tupel toevoegt. 


We kunnen de zojuist genoemde constateringen dat Shipsup(v) €e v(SP) —> v(S) en 
Shippart(v) € v(SP) — v(P) als volgt schematisch weergeven: 


Shipsup(v) Shippart(v) 


Figuur 2.11: Enige functionele verbanden 


Vooral wanneer we te maken hebben met een gróót aantal DB-functies - wat in de 
praktijk vaak het geval is - dan kan zo’n informeel plaatje nog wel eens handig zijn. 
Wellicht ten overvloede merken we op dat omgekeerd zo’n informele schets in het 
algemeen nog niet voldoende is om daaruit de precieze definities van de aangegeven 
functies te kunnen afleiden. 


O Voorbeeld 2.17. 
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Gemakshalve geven we ook nog een overzicht van onze (cumulatieve) 
personen/gemeenten-voorbeelden, die zijn verspreid over de voorbeelden 2.8, 2.13 en 2.14 
en over op opgaven 2.79, 2.84, 2.90 en 2.91. 


Fl= ((STR ; Chs(50)), F4= ((NR ; N-{0}), S2= {‘GR’, ‘FR’, ‘DR’, 
(HNR ; [1 … 5000])}; (NM ; Chs(40)), OV: ET, ‘GE 
F2= {(NR _ ;[1000.. 99997), (ADR ; II(F1)), ‘UT’, ‘NH’, ‘ZH’, 
(LC __ ; Chs(2))}; (PC >; TU(F2)); ZE | BE): 
F3= (DG ;[1.. 31), (WPL ; Chs(30)), F5 = ((WPL ; Chs(30)), 
(MND ; [1 .. 12]), (GBD ; II(F3)), (PROV ; S2), 
OR ; N) (GPL ; Chs(30)), (INWA ; N), 
(NMK; P(Chs(30)))}; (OPVL ; IN), 
(NR ; AN}; 


WP ={T cCII(F4)1 {NR} is ui. in T en 
{PC} — {WPL} in T en 
(ADR, WPL} — {PC} in Ten 
Vte T: als (NR) #1 dan Jt’ € T : (NR) = (NR) — 1}; 
WG ={T cII(FS) | {WPL} is ui. in T}; 
WP2 ={T cII(F4)! {NR} is u.i. in T}; 
WG2 ={T e WG | {NR} is wi. in T}; 
WPE ={Te WP | Tis eindig}; 
WGE ={Te WG | Tis eindig}; 


F6 = ((PERS; WP), (GEM; WG)}; 
F7 = {(PERS; WP2), (GEM; WG)}; 
F8 = {(PERS; WPE), (GEM; WGE)}: 


U1 = {v e II(F6) | id({WPL}) verbindt v(PERS) met v(GEM) en 
id({NR, WPL}) verbindt GEM) met v(PERS) }; 
U3 = {v e II(F7) | id({ WPL}) verbindt v(PERS met v(GEM) en 
id({ NR, WPL}) verbindt v(GEM) met v(PERS) en 
{(GPL; WPL)} verbindt (PERS) met (GEM) }; 
U4 = U3 A II(F8); 


H2=Ave U1: {(t;t’) © (GEM) x (PERS) | (NR) = t’(NR)}; 
H3 = àv e U1: {(t;t’) € (PERS) x (GEM) | (GPL) = t’(WPL)}: 
H4 = H2} U4; 

H5 = H3} U4. 
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We besluiten Hoofdstuk 2 met enige herhalingsopgaven. 


OPGAVEN 


2.93. We definiëren de zogeheten (left) outer join van een tabel T over een verzameling A 
met een tabel 7’ over een verzameling A’ als volgt: 


T T 2 (TTU (T-T pa T’) | A)). 


(a) Is de verzameling T >< T’ altijd, dat wil zeggen voor alle tabellen T en T’, for- 
meel weer een tabel? Licht uw antwoord toe met een bewijs of een tegenvoor- 
beeld. 


(b) AlsT | A’cT’ | AdanT p<T'=T pq T. Bewijs dit. 
(c) Is de left outer join commutatief? 
(Met andere woorden, geldt altijd T >< T’ =T p< T ?) 
In Figuur 2.2 in Voorbeeld 2.2 zijn de tabellen V1 en V2 weergegeven. 


(d) Geef het aantal elementen van de verzamelingen V1 >< V2 en V2 p< V1. 
(e) Probeer ook V1 >< V2 en V2 P< V1 in een figuur weer te geven. 


2.94. We definiëren: 
(D1) Als A en B verzamelingen zijn, c ¢ (A —B) en T is een tabel over A, dan: 
Packg (T) = {t}B U {(c;t} B} Ite T) 
(D2) Als A en B verzamelingen zijn, ae A,B A (A — {a}) =Ø, T is een tabel over A 
en Vt e T : t(a) is een functie over B, dan: 
Unpack,(T) = {t} {a} U t(a) | te T}. 
Beantwoord de volgende vragen. 
(a) Zijn Packg ¿(T) en Unpack, (T) weer tabellen? 
Zo ja, over welke verzamelingen? 
Bewijs de volgende twee gelijkheden en geef in elk van de beide gevallen de precieze 
voorwaarden (voor a,B,T, etcetera) aan. 
(b) Unpack,(Packg ,(T)) =T. 
(c) Packg (Unpack, (T)) =T. 
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2.95. 


2.96. 


2.91. 


2.98. 


2.99. 


Geldt er gelijkheid in Opgave 2.17(b)? Geef een bewijs of een tegenvoorbeeld. 


Laat A, B en C verzamelingen zijn en T een tabel over A. We definiëren: 

B >CinT VteT:Vt'eT: alst} B =t} B dan tot’ | Oe T. 

(We noemen dan C meerwaardig afhankelijk van B in T; 

in het Engels: C is multivalued dependent on B within T.) 

(a) AlsBcAenCcAenB >CinTdanB >» CinT. 
Bewijs dit. 

(b) Geef een voorbeeld van een meerwaardige afhankelijkheid die niet een momen- 
tane afhankelijkheid is. 


(c) Bewijs de volgende equivalentie: 
B—»CinT <> T=T|(BVUVCOPATI(BV(A-C)). 


Als A, A’ en A” verzamelingen zijn en T is een tabel over A en T’ is een tabel over A’ 
en T” is een tabel over A” en h en k’ zijn injectieve functies met dom(h) CA en 
mg(h) c mg(h’) en dom(h’) c A’ en mg(h’) c A” en h verbindt T met T’ en k’ ver- 
bindt T’ met T”, dan verbindt k’ o h de tabel T met T”. 

Bewijs dit of geef een tegenvoorbeeld. 


Als A en A’ verzamelingen zijn en T is een tabel over A en T’ is een tabel over A’ en h 
is een injectieve functie en dom(h) < A en rng(h) < A’ dan: 


h verbindt T met T’ <> T =T pq (T’ ee h). 


Bewijs dit. 


Als T en T’ verzamelingen functies zijn en C is een verzameling en h is een injectieve 
functie, dan: 
(a) id(C) verbindt T bilateraal met T’ <> id(C) verbindt T’ bilateraal met T; 


(b) A verbindt T bilateraal met T’ <=> h`! verbindt T’ bilateraal met T. 
Bewijs dit. 


88 ENIGE CENTRALE DATABASE-BEGRIPPEN 


2.100. In de (SQL-)praktijk moet men voor gegeven attributentransformatie h en tabellen T 
en T’ vaak de volgende equivalentie gebruiken: 


h verbindt T met T” <> O=l(teTlO=l(teT’ It] dom(h)=t'e h}I}I. 


Bewijs dit gezochte gedrocht. 


2.101. Bepaal de verzameling van alle minimale sleutels van de verzameling W3 bestaande 
uit de volgende 3 tabellen: 


T23: 


Licht uw antwoord kort toe. 


2.102. Als A en B verzamelingen zijn en W is een verzameling tabellen over A, geldt dan 
B is een minimale sleutel van W <> VT e W : B is minimaal u.i. in T ? 


Onderzoek beide implicaties afzonderlijk op hun correctheid. 


2.103. We definiëren: 
Als A een verzameling is en W is een verzameling tabellen over A, dan: 
W is in 2NF <> Va e Sec(W): VS € Ms(W): VB CS: als B % {a} in W dan B =S. 
Dus, informeel verwoord, W is in 2NF (tweede normaalvorm) desda elke secundair 
attribuut "volledig afhankelijk" is van elke minimale sleutel van W. 
(a) Als W in 3NF is dan is W in 2NF. Bewijs dit. 
(b) Is WP uit Voorbeeld 2.8 in 2NF? 


2.104. Deze opgave is een vervolg op Opgave 2.96. We introduceren hier het begrip 
meerwaardige afhankelijkheid (multivalued dependency) op het niveau van tabellen- 
verzamelingen. Ook voeren we in deze opgave de vierde normaalvorm in. 

Als A, B en C verzamelingen zijn en W is een verzameling tabellen over A, dan 
definiëren we: 
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(DI) B -$ CinW @&VTeW:B >Cinr. 


(D2) Wisin4NF <& YX c Head(W) : VY c Head(W): 
als X > YinWenYd XenX UY c Head(W) 
dan is X een sleutel van W. 


(a) Als Win 4NF is, dan is W ook in BCNF. Bewijs dit. 
(b) Is@in4NF? 
(c) Is WA uit Voorbeeld 1.3 in 4NF? 


2.105. Definieer naar aanleiding van het DB-universum in Voorbeeld 2.13 een DB- 
universum UNED dat wél precies de Nederlandse situatie weerspiegelt. 


O 


3 CONSTRUCTIE VAN DATABASE-UNIVERSA 


In Hoofdstuk 1 hebben we gedefinieerd wat een DB-universum in theorie is. In dit hoofdstuk 
zullen we aangeven hoe een DB-universum in de praktijk kan worden geconstrueerd. 


Definities van DB-universa plegen in de praktijk nogal omvangrijk te zijn. Het is bijvoor- 
beeld niet ongebruikelijk dat er ten behoeve van de werkzaamheden van één enkele afdeling 
binnen een organisatie wel een paar honderd attributen nodig zijn, dit dus nog afgezien van 
de beschrijving van de vele eisen waaraan de gegevens dienen te voldoen. Het is daarom van 
belang om constructies van DB-universa op een stelselmatige wijze op te bouwen. Boven- 
dien is het verstandig om dit bij voorkeur op een modulaire wijze te doen aangezien (gedeel- 
ten van) bestaande DB-universa nog wel eens aan verandering onderhevi g willen zijn. 


Wij zullen in de constructie van een DB-universum over een gegeven DB-skelet g vier 
"fasen" onderscheiden en aan elke fase een paragraaf wijden. (Het bepalen van het DB- 
skelet zelf vormt nog een fase apart; zie 83.0.) Deze vier fasen bestaan uit het bepalen van 


(1) de verzameling toegestane attribuutwaarden per attribuut per tabelindex, 
(2) de verzameling toegestane tupelwaarden per tabelindex, 
(3) de verzameling toegestane tabelwaarden per tabelindex, en ten slotte 


(4) de verzameling toegestane database-waarden. 


VOORBEELD 3.1: 


In Voorbeeld 1.3 zijn de betreffende verzamelingen (uitgaande van het eerder in Voor- 
beeld 1.2 reeds gegeven DB-skelet g1): 
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(1) de verzameling FM(a) voor elk attribuut a horend bij de tabelindex MEDEW en 
de verzameling FA(a) voor elk attribuut a horend bij de tabelindex AFD, 


(2) II(FM) voor MEDEW en II(FA) voor AFD, 
(3) WM voor MEDEW en WA voor AFD, en ten slotte 
(4) VBU. 

Voorbeeld 3.1. 


De waardenverzamelingen worden in feite bepaald door de eisen waaraan de gegevens in 
alle mogelijke toestanden volgens de organisatie in kwestie dienen te voldoen. Deze eisen 
aan de mogelijke toestanden worden in de literatuur wel statische constraints genoemd. 
Behalve statische constraints zullen we in Hoofdstuk 5 ook dynamische constraints behan- 
delen, dat zijn de eisen waaraan toestandsovergangen dienen te voldoen. 


Dergelijke eisen, die in dit verband ook wel “business rules" worden genoemd, weer- 
spiegelen in wezen voor een belangrijk gedeelte de “semantiek” van de gegevens voor de 
organisatie in kwestie! Eén van de doelstellingen van dit boek is dan ook de lezer te laten 
zien hoe deze semantiek formeel kan worden gespecificeerd. 


Zoals reeds beschreven in bijvoorbeeld [Re 82] en [Br 80] kunnen we parallel aan de eerder 
genoemde fasering van de constructie van een DB-universum ook vier soorten statische con- 
straints onderscheiden: 


(1) Attribuutconstraints; dit zijn voorwaarden waaraan de waarden van de afzonderlijke 
attributen moeten voldoen. 


(2) Tupelcontraints (of "inter-attribuut" constraints); dit zijn voorwaarden waaraan com- 
binaties van attribuutwaarden binnen hetzelfde tupel moeten voldoen. 


(3) Tabelconstraints (of "inter-tupel" constraints); dit zijn voorwaarden waaraan com- 
binaties van tupels binnen dezelfde tabel moeten voldoen. 


(4) Databaseconstraints (of "inter-tabel" constraints); dit zijn voorwaarden waaraan com- 
binaties van tabellen binnen dezelfde DB-toestand moeten voldoen. 


Deze vier soorten zijn dus geordend naar toenemende "reikwijdte". 


We zullen in elk van de te bespreken fasen de behandelde stof larderen met verwijzingen 
naar de in de vorige hoofdstukken gegeven voorbeelden en ook alvast naar het grote voor- 
beeld in Hoofdstuk 4. Daarnaast zullen we de behandelde stof ook telkens nog toelichten aan 
de hand van een klein, maar gevarieerd modelleringsvoorbeeld. Dit “Madurodam van de 
gegevensmodellering" wordt daarbij stap voor stap opgebouwd. 
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3.0 HET DATABASE-SKELET 


In feite is er ook nog een "nulde" fase, namelijk de fase waarin de relevante tabelindexen en 
de relevante attributen per tabelindex - kortom het juiste DB-skelet g - worden bepaald. In de 
praktijk wordt deze fase van het ontwerpproces nogal eens onderschat, zowel qua 
moeilijkheidsgraad als qua tijdsduur. De belangrijkste reden hiervoor is dat de toekomstige 
gebruikers van de database bij nader inzien vaak zelf ook niet precies weten wat de feitelijke 
structuur van hun organisatie en hun gegevens is, en wat daarvan wel en wat niet relevant is. 


Tot nu toe hebben we één expliciet voorbeeld van een DB-skelet genoemd, en wel het DB- 
skelet gl in Voorbeeld 1.2: 


gl={(AFD _ ; (ANR, MANNR, NAAM), 
(MEDEW ; (AFDNR, NR, NAAM, GESL, SAL})} 


Het DB-skelet g1 kent zowel zogeheten homonieme attributen als zogeheten synonieme attri- 
buten: 


— De attributen NAAM van AFD en NAAM van MEDEW zijn "homoniem" 
(dat wil zeggen gelijknamig maar met verschillende "betekenissen". 


— _De attributen ANR van AFD en AFDNR van MEDEW zijn "synoniem" 
(dat wil zeggen ongelijknamig maar met dezelfde "betekenis". 


De volgende verzamelingsfunctie, g2, is het gemeenschappelijke DB-skelet van de DB- 
universa U1, U3 en U4 zoals die in het overzicht aan het eind van 82.4 voorkomen: 


g2 = {(PERS ; (NR, NM, ADR, PC, WPL, GBD, GPL, NMK }), 
(GEM ; {WPL, PROV, INWA, OPVL, NR})}. 


Het DB-skelet van het DB-universum UZKH in §4.2 bestaat uit 19 tabelindexen met in 
totaal 128 attributen. Voorbeelden van tabelindexen zijn hier PAT, MW, MED en MVS. 


VOORBEELD 3.2: 
In een produktiebedrijf wil men gegevens bijhouden over de produkten die men zelf 
maakt en over de basisprodukten die men daarvoor inkoopt. Bovendien wil men 
zogeheten stuklijsten bijhouden, dat wil zeggen lijsten die de directe onderdelen van 
samengestelde produkten opsommen en daarbij tevens aangeven hoe vaak dat onder- 
deel als direct onderdeel in dat produkt optreedt. Een stuklijst wordt ook wel een Bill 
Of Material (of kortweg BOM) genoemd. Stuklijsten spelen een centrale rol in 
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produktiebedrijven en geven bovendien aanleiding tot allerlei interessante wiskundige 
vragen. Deze vragen zijn vaak recursief van aard. 


Van elk produkt wil men in het onderhavige produktiebedrijf het produktnummer, de 
omschrijving, de produktsoort, de kostprijs per stuk, de verkoopprijs per stuk, de winst 
per stuk en de aanwezige voorraad bijhouden. (Alle prijzen zijn in centen uitgedrukt.) 
Bovendien wil men van elk produkt weten of het een samengesteld produkt dan wel 
een basisprodukt is. 


Van elk basisprodukt wil men verder bovendien nog bijhouden wat het gewicht is en of 
de gebruikte gewichtseenheid nu gram dan wel kilogram is. 


Verder wil men dus weten welke produkten welke directe onderdelen bevatten en in 
welk aantal stuks. Dit gebeurt op basis van zogeheten stuklijstregels. 


Dit brengt ons tot het volgende DB-skelet: 


GBP = ((PROD ; (PNR, OMS, SRT, KPR, VKP, WNST, VRD, SAM}), 
(BAS ; {PNR, GW, GWE}), 
(BOM ; {PNR, ONR, AST})}. 


Ter illustratie geeft Figuur 3.2 een representatieve DB-toestand v2 over GBP weer. We 
geven in Figuur 3.1 echter eerst een grafische weergave van de (assemblage)gegevens 
die in v2(BOM) voorkomen, aangevuld met de omschrijvingen uit v2(PROD). Het laat 
daarmee de hiërarchische produktopbouw nog eens op een overzichtelijke wijze zien; 
en omgekeerd laat Figuur 3.2 dus zien hoe dergelijke hiërarchische structuren (zoals 
bomen en andere grafen) in tabellen kunnen worden weergegeven! 
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de Se el 
Se el + moer T 


Figuur 3.1: Een grafische weergave van v2(BOM), 
aangevuld met de omschrijvingen uit v2(PROD) 


69333 
Bureaublad 


Bout + moer 
Lade 
Ladenhouder 
Lade 

Bureau 
Duimschroef 
Pennenbakje 
Bureaublad 
Opbergwand 
Ladenkast 
Gewone kast 
Steun 
Plank 
Ombouw 
Steundeel 
Ladeplank 
Bureaustoel 


222222 Z 


(a) De tabel v2(PROD) 
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O Voorbeeld 3.2. 


OPGAVE 


28325 | 87384 
11297 | 87384 i 
44660 | 87384 6 
11297 | 44660 6 
11198 | 44660 2 
44022 | 44660 j. 
69333 | 87384 1 
11198 | 40007 3 
11198 | 55803 16 
11198 | 52250 16 
40007 | 55803 8 
40007 | 52250 8 
(b) De tabel v2(BAS) 40007 | 81290 16 
40018 | 40007 2 
44600 | 55803 4 
44660 | 81290 3 
55803 | 81290 1 
52250 | 81290 2 
44066 | 52250 4 
44066 | 81290 8 
25762 | 52250 1 
25762 | 55803 1 
44704 | 87384 2 
(c) De tabel v2(BOM) 


Figuur 3.2: De DB-toestand v2 over GBP 
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3.0. Bedenk zelf enige relevante tabelindexen met relevante attributen voor een of andere 
organisatie (bijvoorbeeld een warenhuis, een ziekenhuis of een software-huis). 


m 
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3.1 SPECIFICATIES VAN TOEGESTANE ATTRIBUUTWAARDEN 


Voor elke tabelindex E in dom(g) kunnen de verzamelingen toegestane attribuutwaarden 
worden vastgelegd door middel van een verzamelingsfunctie F over g(E). Met andere woor- 
den, F is de functie die voor elke attribuut a van E de verzameling toegestane waarden voor 
a binnen E vastlegt. In [Re 82] heet zo’n verzamelingsfunctie een objectkarakterisering. 


In de database-literatuur wordt onder een relatieschema soms verstaan een verzameling attri- 
buten waarbij aan elk attribuut (impliciet) ook een waardenverzameling is “gekoppeld”. In 
dat geval wordt met een relatieschema dus in feite een objectkarakterisering bedoeld. Als 
voorbeeld van zo’n literatuurplaats noemen we [Mai 83], pagina 2. (Overigens bedoelt men 
met een relatieschema meestal de verzameling g(E), zoals bijvoorbeeld in [U1 82] en [Ya 
86], dan wel het paar (E ; g(E)), zoals bijvoorbeeld in [U1 82] en [CP 87].) 


Tot nu toe hebben we de volgende voorbeelden van objectkarakteriseringen gezien: 
— FM en FA, reeds geïntroduceerd in Voorbeeld 0.1 en gebruikt in Voorbeeld 1.3; 


—  F4 in Voorbeeld 2.8, gedefinieerd met behulp van de functies F1, F2 en F3 die, hoewel 
ze wel de vorm van een objectkarakterisering hebben, daar niet als zodanig dienst 
doen; 


— FPCB in Voorbeeld 2.12, ook gedefinieerd met behulp van de "module" F2; 


— F5 in Voorbeeld 2.13, gedefinieerd met behulp van S2, de verzameling die de 
gebruikelijke afkortingen van de twaalf provincies van Nederland opsomt. 


In $4.2 is er voor elk van de 19 tabelindexen een objectkarakterisering te vinden. Voorbeel- 
den zijn de functies FPAT, FMW en FMVS. Voorbeelden van attribuutconstraints in 
Hoofdstuk 4 zijn de randvoorwaarden R03, R04, ROS, R06, R46 en R53. Ook R02 is hier een 
attribuutconstraint. Naast deze "genummerde" attribuutconstraints zijn er ook nog vele niet- 
genummerde attribuutconstraints; voorbeelden hiervan zijn de eisen dat een intern telefoon- 
nummer 4-cijferig dient te zijn en dat een specialistenhonorarium ten minste 80 gulden per 
uur moet bijdragen. 


Een ander aardig voorbeeld van een attribuutconstraint is de eis dat een bankrekeningnum- 
mer altijd aan de zogeheten 11-proef moet voldoen, dat wil zeggen dat 1 maal het 9© cijfer 
plus 2 maal het 8° cijfer plus … plus 8 maal het 2€ cijfer plus 9 maal het 1€ cijfer een getal 
moet opleveren dat deelbaar is door 11. De verzameling toegestane bankrekeningnummers is 
derhalve 
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{n e Vng(9) | (Zie [1.. 9]: i * ((n div 10") mod 10)) mod 11 = 0}. 


Meestal echter is een verzameling toegestane attribuutwaarden van het simpele "type-plus- 
lengte" formaat, zoals bijvoorbeeld Chs(30), Vng(9) of Int(4). Andere niet ongebruikelijke 
vormen van verzamelingen toegestane attribuutwaarden zijn intervallen (alias "subranges"), 
bijvoorbeeld [1 … 31] voor dagen in een maand of [—273 … voor temperaturen. 


Soms wordt een verzameling attribuutwaarden bepaald door enumeratie (dat wil zeggen 
door de elementen één voor één op te noemen), zoals bijvoorbeeld de verzameling { ‘MAN’, 
‘VROUW’ }, de verzameling { ‘Uitstekend’, ‘Goed’, ‘Voldoende’, ‘Matig’, ‘Slecht’ } of 
de verzameling (1, 3, 5, 7,8, 10, 12} (voor de maanden met 31 dagen). 


Wanneer het aannemelijk is dat de enumeratieve waardenverzameling van een attribuut a in 
de loop der tijd nog wel eens aan verandering onderhevig zal zijn, dan is het misschien beter 
om voor a een iets ruimere waardenverzameling te kiezen en een aparte "éénkoloms-tabel" 
te introduceren. Deze nieuwe tabel dient dan op elk moment precies alle op dat moment toe- 
gestane waarden voor attribuut a te bevatten. Bovendien moet daarbij dan ook de 
(database)constraint worden toegevoegd dat elke a-waarde in de oorspronkelijke tabel ook 
voorkomt in de zojuist genoemde éénkoloms-tabel; deze databaseconstraint vormt zo als het 
ware een “variabele attribuutconstraint". Gezien de kennelijke “semantiek” van de drie 
zojuist genoemde voorbeelden van enumeratieve verzamelingen komt vermoedelijk alleen 
de "waarderingsverzameling" voor zo’n flexibeler oplossing in aanmerking. In dat geval zou 
als ruimere waardenverzameling bijvoorbeeld Chs(20) gekozen kunnen worden en de 
nieuwe tabel zou dan (voorlopig) uit vijf tupels bestaan (zoals weergegeven in Figuur 3.3). 


Uitstekend 
Goed 

Voldoende 
Matig 
Slecht 


Figuur 3.3 


We gaan nu verder met de opbouw van ons BOM-voorbeeld. 


98 


VOORBEELD 3.3: 


CONSTRUCTIE VAN DATABASE-UNIVERSA 


We introduceren als vervolg op Voorbeeld 3.2 één hulpverzameling, te weten de ver- 
zameling DPN van mogelijke produktnummers, en drie objectkarakteriseringen: 


DPN = {k e Vng(5) | k mod 11 =0}; 


FPROD= {(PNR__ ; DPN), 

(OMS ; Chs(30)), 

(SRT  ; Chs(6)), 

(KPR ; N), 

(VKP ; IN), 

(WNST ; IN —{0})), 

(VRD ; N), 

(SAM ;{‘J’, ‘N’})}; 
FBAS = {(PNR_ ;DPN), 

(GW ;[1.. 10%), 

(GWE; { ‘GR’, ‘KG’})}; 
FBOM = {(PNR _ ; {k e DPN | k2 40000}), 

(ONR ; N), 

(AST: ;[1..))} 


Merk op dat de als het ware 


produktnummer (VOL 
omschrijving 

soort produkt 

kostprijs per stuk 

verkoopprijs per stuk 

winst per stuk (V02 
voorraad 

samengesteld produkt? 
produktnummer 

gewicht 

gewichtseenheid (gram of kilo) 
produktnummer (V03 
onderdeelnummer 

aantal stuks van dat directe 

onderdeel 


"buiten haakjes" gehaalde verzameling 


(ke Vng(5) | k mod 11 = 0} op drie verschillende plaatsen wordt gebruikt. 


Het is eenvoudig na te gaan dat de DB-toestand v2 uit Voorbeeld 3.2 voldoet aan de 


hierboven gestelde eisen of, om precies te zijn, dat 


v2(PROD) c II(FPROD) en v2(BAS) c II(FBAS) en v2(BOM) c II(FBOM). 


O Voorbeeld 3.3. 


Voor attribuutwaarden komen niet alleen getallen en strings in aanmerking. In principe kan 
volgens onze theorie een attribuutwaarde een willekeurig "object" zijn, bijvoorbeeld 
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— een werktekening (in een CAD/CAM-omgeving bijvoorbeeld), 

— een pasfoto (van een werknemer bijvoorbeeld), 

— een plattegrond (voor een autonavigatiesysteem bijvoorbeeld), 

—  eencompact disc (in een juke-box bijvoorbeeld), 

— een handtekening (van een chef bijvoorbeeld), 

— een filmfragment (over een educatief onderwerp bijvoorbeeld), 

— een telefoongesprek (met een klant bijvoorbeeld), of 

— een röntgenfoto (van een patiënt bijvoorbeeld). 

Sommige (zelfs commercieel beschikbare) database-managementsystemen bieden reeds 
ondersteuning voor zulke "objectgeoriénteerde" mogelijkheden, zie bijvoorbeeld [IDT 88] of 
[NGI 88]. Een belangrijke vraag hierbij is telkens of het DBMS ook bijpassende operaties op 
deze bijzondere attribuutwaarden ter beschikking stelt. Voor enkele voorbeelden van object- 


georiënteerde databases en de daarbij behorende operaties verwijzen we naar het overzichts- 
artikel [HK 87] en naar de daarin genoemde referenties. 


Dat onze theorie ook zulke onorthodoxe attribuutwaarden toelaat, is te danken aan het feit 
dat zij, in tegenstelling tot de meeste andere theorieën, geen a priori veronderstellingen over 
de aard van de attribuutwaarden bevat. Zo is in het bijzonder de door ons eerder genoemde 
(doch niet geroemde) eerste-normaalvormeis uit den boze. 


OPGAVEN 


3.1. Geef de voorwaarden vervat in V01, V02 en V03 van Voorbeeld 3.3 in woorden weer. 


3.2. Bedenk voor elk van uw tabelindexen (met bijbehorende attributen) uit Opgave 3.0 een 
plausibele objectkarakterisering. 


O 
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3.2 SPECIFICATIES VAN TOEGESTANE TUPELWAARDEN 


De verzameling toegestane tupels (ofwel tabelementen) voor een tabelindex E met 
objectkarakterisering F is altijd een deelverzameling van II(F). In de meeste gevallen is het 
TICF) zelf, zoals tot nu toe in onze voorbeelden ook steeds het geval is geweest, maar in som- 
mige gevallen zijn niet al deze combinaties van attribuutwaarden toegestaan en zal de ver- 
zameling toegestane tupels een echte deelverzameling van II(F) zijn. Het ontbreken van 
tupelconstraints wijst er op dat de attributen in kwestie kennelijk "onderling onafhankelijke 
grootheden" representeren. 


In het grote voorbeeld in Hoofdstuk 4 is in negen van de negentien gevallen de verzameling 
toegestane tupels een echte deelverzameling van het gegeneraliseerde produkt van de betref- 
fende objectkarakterisering. Die echte deelverzamelingen zijn TPAT, TSP, TWN, THA, 
TPLR, TAFD, TRU, TOPN en TBEH. Deze negen verzamelingen worden bepaald door in 
totaal vijftien tupelconstraints, te weten de randvoorwaarden RO7, R14, R17, R21, R22, R27, 
R40, R41, R44, R51, R55, R56, R58, R59 en R77. 


Andere typische voorbeelden van eisen op tupelniveau, dus eisen tussen attribuutwaarden, 
kunnen zijn: “nettobedrag kleiner dan brutobedrag", "minimaal gewicht (of aantal, of prijs, 
of tijdsduur) niet groter dan maximaal gewicht (respectievelijk aantal, prijs of tijdsduur)”, 
“(werknemersnummer van) de afdelingschef is niet tevens (dat van) de souschef", "van elke 
aangesloten vereniging moeten (de lidmaatschapsnummers van) voorzitter, penningmeester 
en secretaris onderling verschillend zijn" en "als de rekeningsoort niet ‘GIRO’ is, dan moet 
het rekeningnummer aan de 11-proef voldoen". 


In §4.1 luidt de randvoorwaarde R31 (voor niet-medisch personeel): "Het maandelijkse ver- 
goedingsbedrag mag niet boven het maandsalaris uitkomen". Hoewel R31 op het eerste ge- 
zicht een tupelconstraint lijkt, blijkt in §4.2 dat het toch een databaseconstraint is. De reden 
hiervoor is dat door generalisatie - zie 83.4 - de gegevens over het niet-medisch personeel 
zich in verschillende tabellen bevinden, in casu het vergoedingsbedrag gewoon in de NMP- 
tabel maar het maandsalaris in de (meer algemene) werknemerstabel. Dit betekent dat R31 
moet worden uitgedrukt in termen van de join van die twee tabellen. (Binnen dat join- 
resultaat, wat volgens Lemma 2.5(a) ook een tabel is, is R31 wel een "tupelconstraint".) Eén 
van de conclusies van dit voorbeeld is dan ook dat de classificatie van een constraint niet een 
"absolute" eigenschap van die constraint is, maar kan afhangen van het uiteindelijk te kiezen 
DB-skelet bijvoorbeeld. 
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VOORBEELD 3.4: 


We breiden Voorbeeld 3.3 uit met de volgende verzamelingen toegestane tupels: 


TPROD = {t e II(FPROD) | ((VKP) 2 2 x t(KPR) en (V04) 
t(WNST) = t(VKP) — t(KPR) en (V05) 
(t(VRD)< 2 of (VRD) x (KPR) < 10°)}; (V06) 
TBAS = {te II(FBAS) | als (¢GWE) = ‘GR’ dan t (GW) < 10000}; (V07) 
TBOM = {te II(FBOM) | (ONR) #¢(PNR)}. (V08) 


Merk op dat we nu reeds kunnen constateren dat {VKP, KPR} — {WNST} in 
TPROD; zie Opgave 3.7. 


Omdat FPROD(WNST) = N — {0} en FPROD(KPR) = N, volgt uit voorwaarde VOS 
dat bij elementen van TPROD een verkoopprijs nooit 0 is. In feite is dit een voorbeeld 
van een “verborgen” attribuutconstraint die volgt uit een tupelconstraint. 


O Voorbeeld 3.4. 


OPGAVEN 


35 


3.4. 


Saas 


3.6. 


i S 


3.8. 


Geef de vijf voorwaarden in Voorbeeld 3.4 in woorden weer. 
Geef enige elementen van TPROD, van TBAS en van TBOM. 


Geef enige elementen van II(FPROD) — TPROD, van II(FBAS) — TBAS en van 
II(FBOM) — TBOM. 


Voldoet de DB-toestand v2 uit Voorbeeld 3.2 aan alle in Voorbeeld 3.4 gestelde eisen? 
(Met andere woorden, is het zo dat v2(PROD) c TPROD, v2(BAS) c TBAS en 
v2(BOM) c TBOM ?) 


Bewijs het volgende: 

(a) {KPR, VKP} — {WNST} in TPROD; 
(b) {KPR, WNST} — {VKP} in TPROD; 
(c) {VKP, WNST} — {KPR} in TPROD; 


Breid uw oplossing bij Opgave 3.2 uit met bijbehorende verzamelingen toegestane 
tupels. 
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3.3 SPECIFICATIES VAN TOEGESTANE TABELWAARDEN 


Als Y de verzameling toegestane tupels voor een tabelindex E is, dan is de verzameling toe- 
gestane tabellen voor E een (meestal echte) deelverzameling W van P(Y). Dus, elke toege- 
stane tabel voor E is een deelverzameling van Y terwijl, omgekeerd, niet noodzakelijk elke 
deelverzameling van Y een toegestane tabel voor E is. 


Tot nu toe hebben we onder andere de volgende voorbeelden van zulke tabellenverzame- 
lingen W gezien: 


— WMen WA in Voorbeeld 1.3; 

—  WPCB in Voorbeeld 2.12; 

— WP en WG in Voorbeeld 2.13; 

—  WG2 (en passant) in Voorbeeld 2.14; 
— WP2 in Opgave 2.79; 

— WPE en WGE in Opgave 2.90. 


Verder hebben we in de opgaven 2.47 en 2.101 ook nog enige "kunstmatige" (definities van) 
tabellenverzamelingen gegeven. De tabellenverzamelingen W1 en W2 in Opgave 2.47 en 
W3 in Opgave 2.101 zijn namelijk gedefinieerd door één voor één hun elementen op te noe- 
men en niet, zoals gebruikelijk, door hun karakteriserende eigenschappen op te noemen. 


In §4.2 definiëren we 19 tabellenverzamelingen. Ze worden allemaal gebruikt in de definitie 
van FZKH, vlak voor de definitie van UZKH. Voorbeelden van deze tabellenverzamelingen 
zijn WPAT, WMW, WMED en WMVS. We tellen daarbij in totaal 33 tabelconstraints. 


De belangrijkste eisen op tabelniveau zijn die van momentane afhankelijkheid en in het 
bijzonder die van unieke identificatie (zoals ook onze voorbeelden al wel suggereren). 
Andere mogelijke eisen op tabelniveau zijn bijvoorbeeld eisen aangaande het gemiddelde of 
totale salaris (al dan niet per afdeling) en eisen omtrent volgnummers, bijvoorbeeld dat ze 
chronologisch en opeenvolgend zijn toegekend (misschien bij de verschillende medicijnver- 
strekkingen van eenzelfde patiënt, om maar eens een voorbeeld uit Hoofdstuk 4 te noemen). 


Tenslotte noemen we nog als mogelijke eis op tabelniveau dat de waardenverzameling van 
het ene attribuut in een tabel bevat moet zijn in de waardenverzameling van een zeker ander 
(meestal uniek identificerend) attribuut van die zelfde tabel. Meer in het algemeen is dit een 
tabelconstraint van de vorm: h verbindt T met T. Een voorbeeld hiervan is R18 in §4.2. De 
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randvoorwaarde R26 in §4.2 gaat zelfs nog een stapje verder. Elk van deze eisen is een voor- 
beeld van een interne ssr, waarbij "ssr" een afkorting is voor subset requirement. (In de vol- 
gende paragraaf zullen we hier nader op ingaan.) 


VOORBEELD 3.5: 
We breiden nu Voorbeeld 3.4 uit met de volgende verzamelingen toegestane tabellen: 


WPROD = {T c TPROD | {PNR} is u.i. in T en (V09) 
(Xt e T : (VRD) « (KPR) < 10°}; (V10) 
WBAS ={TCTBAS |{PNR}isui.inT}; (V11) 
WBOM = {T c TBOM | {PNR, ONR} is u.i. in T en (V12) 
{(t(ONR); t(PNR)) | t e T} is acyclisch}. (V13) 


De relatie {(t(ONR); t(PNR)) | t e T} wordt wel een assemblage-relatie genoemd en de 
inverse ervan, dus de relatie {(t(PNR); t(ONR)) | t e T}, wel een explosie-relatie (in 
BOM-terminologie). 


De eis V13 is een voorbeeld van een zogeheten recursieve constraint, en wel omdat er 
in wezen gebruik wordt gemaakt van de transitieve afsluiting van een relatie (zie 
Definitie 0.22). 


Merk op dat V08 nu een "redundante" constraint is geworden; deze tupelconstraint 
volgt uit de tabelconstraint V13 (aldus Lemma 0.18(d)). 


O Voorbeeld 3.5. 


OPGAVEN 


3.9. Geef de vijf voorwaarden in Voorbeeld 3.5 in woorden weer. 


3.10. Voldoet de DB-toestand v2 uit Voorbeeld 3.2 aan alle in Voorbeeld 3.5 gestelde eisen? 
(Geef echter, naar analogie van Opgave 3.6, eerst een iets formelere weergave van deze 
vraag.) 


3.11. Geef een element van P(TBOM) — WBOM waarin (PNR, ONR} uniek identificerend 
iS. 
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3.12. Uit V10 volgt de tupelconstraint dat (VRD) + (KPR)< 108. 
(a) Volgt uit deze tupelconstraint ook V06? 
(b) Volgt deze tupelconstraint ook uit V06? 


3.13. Ga na of WPROD, WBAS en WBOM in 3NF zijn. Beargumenteer uw antwoorden. 


3.14. Breid uw oplossing bij Opgave 3.8 uit met bijbehorende verzamelingen toegestane 
tabellen. 


O 


3.4 SPECIFATIES VAN TOEGESTANE DATABASE-WAARDEN 


Het uiteindelijke DB-universum over g is een (meestal echte) deelverzameling van II(H) 
waarbij H de functie over dom(g) is die aan elke E in dom(g) de bij E gekozen verzameling 
toegestane tabellen toevoegt. Zo’n "tabellenverzamelingswaardige" functie wordt in [Re 82] 
wel een database-karakterisering genoemd. 


Tot nu toe hebben we onder andere de volgende voorbeelden van DB-universa (met 
bijbehorende DB-karakteriseringen) gezien: 


—  VBU met DB-karakterisering HF in Voorbeeld 1.3; 
— Ul met DB-karakterisering F6 in Voorbeeld 2.13; 
— U3 met DB-karakterisering F7 in Opgave 2.79. 


Verder bevat Opgave 2.91 nog een definitie van een DB-universum in een iets andere 
gedaante: 


U4 = U3 A II(F8), 
waarbij F8 een in Opgave 2.90 gedefinieerde DB-karakterisering is. 


Aan het eind van $4.2 vinden we de definitie van het DB-universum UZKH, gebaseerd op de 
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DB-karakterisering FZKH die aan elk van de 19 tabelindexen één van de eerder 
gedefinieerde tabellenverzamelingen toevoegt. We tellen 35 databaseconstraints in de 
definitie van UZKH. 


VOORBEELD 3.6: 

We ronden de voorbeelden 3.2 tot en met 3.5 af met de introductie van de DB- 
karakterisering HBP en het DB-universum UBP (over het eerder genoemde DB-skelet 
GBP). Bovendien voeren we nog de attributentransformatie h5 in; deze functie zullen 
we gebruiken in voorwaarde V17 (en Opgave 3.17). Volledigheidshalve herhalen we 
tevens alle voorgaande definities die betrekking hebben op ons BOM-voorbeeld. (Merk 
echter op dat het DB-skelet GBP verder niet meer expliciet gebruikt hoeft te worden; 
desalniettemin is het vooraf vaststellen van het onderliggende DB-skelet een zeer 
belangrijke en moeilijke taak op zichzelf.) 


GBP = {((PROD ; (PNR, OMS, SRT, KPR, VKP, WNST, VRD, SAM}), 
(BAS ; {PNR, GW, GWE}), 
(BOM ; {PNR, ONR, AST})}; 


h5= {(ONR ; PNR), onderdeelnummer 
(ONDOMS ; OMS), onderdeelomschrijving 
(SRTOND ; SRT), soort onderdeel 
(KPOND ;KPR), kostprijs onderdeel 
(VKPOND ; VKP), verkoopprijs onderdeel 
(PWOND _ ; WNST), potentiéle winst op onderdeel 
(ONDVRD ; VRD), voorraadhoogte onderdeel 
(ONDSAM ;SAM)}; onderdeel zelf samengesteld? 


DPN = {k e Vng(5) |k mod 11 = 0}; 


FPROD = {(PNR _ ; DPN), produktnummer (V01) 
(OMS ; Chs(30)), omschrijving 
(SRT  ; Chs(6)), soort produkt 
(KPR ; WN), kostprijs per stuk 
(VKP ; WN), verkoopprijs per stuk 
(WNST ; N -{0}), winst per stuk (V02) 
(YRD ; AN), voorraad 


(SAM ;{‘J’, ‘N’})}; samengesteld produkt? 
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FBAS= {(PNR _ ; DPN), produktnummer 
(GW. :{1'.. 1); gewicht 
(GWE : { ‘GR’, ‘KG’ })}; gewichtseenheid 
FBOM= {(PNR _ ; {k e DPN| k2 40000}), | produktnummer (V03) 
(ONR ; WN), onderdeelnummer 
(ASE: EEE pN aantal stuks 
TPROD = {t e II(FPROD) | ((VKP) 2 2 x t(KPR) en (V04) 
t(WNST) = t(VKP) — (KPR) en (V05) 
(t(VRD) < 2 of (VRD) « t(KPR)< 10°)}; (V06) 
TBAS = {że II(FBAS) |als:(GWE) = ‘GR’ dan (GW) < 10000}; (V07) 
TBOM = {t e II(FBOM) | t(ONR) # t(PNR)}; (V08) 
WPROD = {T c TPROD | {PNR} is ui. in Ten (V09) 
(Zt e T : (VRD) x (KPR))< 10°}; (V10) 
WBAS ={TCTBAS | {PNR}isu.i.inT}; (V11) 
WBOM ={T c TBOM | {PNR, ONR} is u.i. in T en (V12) 
{(t(ONR); t((PNR)) | t e T} is acyclisch}; (V13) 
HBP = {(PROD ; WPROD), produkten 
(BAS ; WBAS), basisprodukten 
(BOM ; WBOM)}; stuklijstregels 


UBP = {v | v e II(HBP) en 


{(ONR; PNR)} verbindt v(BOM) met v(PROD) en (V14) 
id({PNR}) verbindt v(BOM) bilateraal 

met {t e v(PROD) | (SAM) = ‘J’} en (V15) 
id({PNR}) verbindt v(BAS) bilateraal 

met {t e v(PROD) | (SAM) = ‘N’} en (V16) 
Vp € v(PROD): 

(Zt e (BOM) >< (v(PROD) ee h5) en (PNR) = p(PNR): 

t(KPOND) x t(AST))< p(KPR)}. (V17) 


De laatste eis geeft weer dat de kostprijs van een produkt minimaal de som van de 
kostprijzen van de (eventuele) directe onderdelen is. 
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Uit voorwaarde V14 volgt, in combinatie met V01, dat alle ONR-waarden in de 
BOM-tabel elementen van DPN zijn. We zien hier dus een voorbeeld van een "verbor- 
gen” attribuutconstraint die volgt uit een databaseconstraint. Enerzijds hadden we deze 
(voor de hand liggende) attribuutconstraint meteen kunnen opnemen in de betreffende 
objectkarakterisering, anderzijds blijkt deze eis dus in principe overbodig te zijn. 


O Voorbeeld 3.6. 


Veruit de belangrijkste klasse van databaseconstraints is de algemene klasse van 
verbindingseisen, ook wel subset requirements (of kortweg ssr’s) genoemd. Verbindings- 
eisen zijn er echter in allerlei “soorten en maten”. We zullen daarom een paar speciale 
deelklassen nader bekijken. 


(A1) De volgende (elementaire) vorm van verbindingseisen komt in de praktijk het meest 
voor: 


h verbindt v(M) met v(D) 


Deze "standaardvorm" wordt ook wel een referential integrity constraint genoemd. Als 
bovendien mg(h) een sleutel van de D-tabel is, wat meestal wel het geval is, dan wordt 
dom(h) ook wel een foreign key genoemd. Een voorbeeld van zo’n elementaire verbin- 
dingseis waarbij deze situatie zich voordoet, is V14 in Voorbeeld 3.6. De attributenver- 
zameling {ONR} van BOM is dus een foreign key volgens dit woordgebruik. 


In de definitie van UZKH in 84.2 zijn de eerste 20 databaseconstraints die daar 
genoemd worden van bovenstaande vorm. Strikt genomen is er alleen bij de formule- 
ring van de randvoorwaarde R52 niet sprake van een foreign key. (Wel is er een binnen 
UZKH equivalente herformulering van R52 mogelijk waarbij {SCNR} wel een foreign 
key blijkt.) 


(A2) Een sterkere maar minder vaak gebruikte vorm van verbindingseis is: 
h verbindt v(M) bilateraal met v(D) 
Het klassieke voorbeeld is hier dat van de orders en de orderregels. Het ordernummer 
van elke orderregel moet ook voorkomen in de ordertabel, terwijl omgekeerd elke 
order ten minste één orderregel moet bevatten (zodat dus het ordernummer van elke 


order ook moet voorkomen in de orderregeltabel). 


Als h injectief is, dan is een eis van de vorm (A2) volgens Lemma 2.15 ook te 
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schrijven als twee afzonderlijke eisen van de vorm (Al). 


Als mg(h) een sleutel van de D-tabel en dom(h) een sleutel van de M-tabel is, dan is in 
elke toestand v de door h geïnduceerde associatie volgens Lemma 2.16 in feite een 
bijectie van v(M) op v(D). We hadden bij de modellering in fase 0 de tabelindexen M 
en D dan ook net zo goed kunnen samennemen tot één tabelindex die zowel de attribu- 
ten van M als die van D erft (minus dom(h), omdat die attributenverzameling al is ver- 
tegenwoordigd door mg(h)). 


(B1) Soms is het zo dat elk M-tupel moet corresponderen met een D-tupel dat voldoet aan 
een speciale nevenvoorwaarde: 


h verbindt v(M) met {t e v(D) | o(t)} 


Anders gezegd, de eis o(t) is een noodzakelijke voorwaarde voor een D-tupel t om 
bijbehorende M-tupels te kunnen hebben. Deze vorm is dus een versterking van de 
vorm onder (A1). Voorbeelden van databaseconstraints van deze vorm zijn R65, R74 
en R84 in $4.2 en de onder (A1) genoemde equivalente herformulering van R52. 


(B2) De volgende vorm is een versterking van (BĲ): 
h verbindt v(M) bilateraal met {t e v(D) | o(t)} 


Hier is het dus zo dat de nevenvoorwaarde precies karakteriseert bij welke D-tupels er 
ook nog M-tupels bestaan. Voorbeelden van randvoorwaarden van deze vorm zijn V15 
en V16 in Voorbeeld 3.6 en R16, R19, R28, R30 en R67 in 84.2. 


Zoals de zojuist aangehaalde voorbeelden misschien al deden vermoeden, is de eis $(t) 
vaak van de vorm “t(a) =wọ", waarbij de waarde wg niet afhangt van het tupel t of de 
DB-toestand v. In dat geval luidt de databaseconstraint dus: 


h verbindt v(M) bilateraal met (te v(D) | t(a)=wo} 


We noemen in dit geval het attribuut a wel een inspectie-attribuut van D en wo wel de 
inspectie-waarde voor M. Ook hier is het dus zo dat men "in de D-tabel zelf" precies 
kan zien bij welke D-tupels er nog M-tupels behoren, en wel aan de a-waarde van de 
D-tupels. 


Uit V15 en V16 in Voorbeeld 3.6 blijkt dat SAM een inspectie-attribuut van PROD is. 
De inspectie-waarde voor BOM is ‘J’ en voor BAS is het ‘N’. Verder blijkt uit R16, 
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R28 en R30 in §4.2 dat SRTM een inspectie-attribuut van MW is. De inspectie- 
waarden voor de tabelindexen SP, MP en NMP zijn hier "toevalligerwijze" achtereen- 
volgens ‘SP’, ‘MP’ en ‘NMP’. Volgens R67 in §4.2 is ONTS een inspectie-attribuut 
van OPN met ‘JA’ als de inspectie-waarde voor de tabelindex ONT. 


Dat de zojuist gegeven bloemlezing van klassen van verbindingseisen zeker geen volledige 
opsomming van alle mogelijkheden is, moge blijken uit de verbindingseisen R24, RO8 en 
R37 in §4.2. 


Als in één van de voorgaande verbindingseisen M en D toevallig dezelfde tabelindexen zijn 
(en in geval van een B1- of B2-vorm de nevenvoorwaarde & ook niet over andere tabelin- 
dexen rept), dan noemen we de betreffende ssr wel een interne ssr en is die constraint in feite 
een tabelconstraint. (Zo reduceert in dit geval bijvoorbeeld de vorm (A1) tot de vorm: h ver- 
bindt T met T.) In $3.3 noemden we als voorbeelden reeds de interne ssr’s R18 en R26 uit 
§4.2. De tabelconstraint R18 is hierbij van de vorm behandeld onder (A1) en R26 is van de 
algemene vorm behandeld onder (B1). 


Als in één van de voorgaande verbindingseisen de tabelindexen verschillend zijn (of de 
nevenvoorwaarde & wel over andere tabelindexen rept), dan noemen we de betreffende ssr 
een externe ssr en is er kennelijk sprake van een echte databaseconstraint. 


Een verbindingseis "komt zelden alleen" (zoals we al eerder lieten doorschemeren): Zo’n 
databaseconstraint treedt meestal op in combinatie met de tabelconstraint dat mg(h) uniek 
identificerend in v(D) is. In dat geval is volgens Lemma 2.16(3) de door h geïnduceerde 
associatie op v(M) x v(D) een functie. Eén van de weinige tegenvoorbeelden is hier de onder 
(A2) genoemde verbindingseis dat elk ordernummer in de ordertabel ook in de orderregelta- 
bel moet voorkomen. 


Als, gegeven een verbindingseis van één van de eerder genoemde vormen, niet alleen mg(h) 
een sleutel van de D-tabel maar ook dom(h) een sleutel van de M-tabel is, dan is volgens 
Lemma 2.16 in elke toestand de door h geïnduceerde associatie een injectieve functie van 
v(M) naar v(D). Anders gezegd, met elk D-tupel correspondeert er maximaal één M-tupel. 
Het is nu dus in elke DB-toestand zo dat er voor sómmige D-tupels als het ware nog enige 
additionele attributen van toepassing zijn, te weten de elementen van g(M) — dom(h), waar- 
bij g(M) de attributenverzameling van de tabelindex M volgens het DB-skelet g is. 


De hierboven geschetste situatie komt onder andere voor rondom de verbindingseis V16 in 
Voorbeeld 3.6, waar {PNR} zowel een sleutel van de BAS-tabel als van de PROD-tabel is. 
Dus voor sommige PROD-tupels zijn er nog de additionele attributen GW en GWE (gewicht 
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en gewichtseenheid) uit de BAS-tabel van toepassing. Merk op dat deze (niet zo ver- 
rassende) formele conclusie conform de laatste opmerking in de vorige alinea in ieder geval 
in Overeenstemming is met de oorspronkelijke informele omschrijving verwoord in Voor- 
beeld 3.2. Andere voorbeelden van verbindingseisen waarbij de bovengenoemde situatie zich 
voordoet zijn R33, R16, R19, R28, R30, R67 en R49 in §4.2 en de laatste eis in de definitie 
van Ul in Voorbeeld 2.13. Wanneer we nu de laatste opmerking in de vorige alinea 
toepassen op de verbindingseis uit Voorbeeld 2.13, dan komen we tot het (wel verrassende) 
inzicht dat woonplaatsattributen ook kunnen worden opgevat als burgemeestersattributen. 
Toepassing op de verbindingseis R49 in $4.2 leidt nu tot de conclusie dat afdelingsattributen 
ook kunnen worden opgevat als souschef-attributen in dat voorbeeld. Dat het afdelingsnum- 
mer uiteindelijk toch "wezenlijker" voor een AFD-tupel is dan het souschefnummer zal pas 
blijken uit de dynamische constraints in 85.2, in het bijzonder uit C00. (Zie ook de opmer- 
kingen over primary keys en alternate keys in §5.1.) 


Als de door h geïnduceerde associatie in elke toestand v van een DB-universum U een injec- 
tieve functie van v(M) naar v(D) is, dan zeggen we wel dat M een specialisatie of differen- 
tiatie van D is. In sommige gevallen wordt M ook wel een subtype van D genoemd. Volgens 
deze terminologie is bijvoorbeeld BAS een specialisatie van PROD in Voorbeeld 3.6 
(dankzij V16), VV een specialisatie van WN in $4.2 (dankzij R33) en ONT een specialisatie 
van OPN in §4.2 (dankzij R67). 


We noemen een tabelindex D een generalisatie van een tabelindexverzameling X in een 
DB-universum U als elk element M van X een specialisatie van D is en er bovendien in elke 
toestand van U bij elk D-tupel precies één tupel van precies één tabelindex uit X behoort. Bij 
de drie zojuist genoemde specialisaties is er geen sprake van generalisatie. Wel is in 84.2 de 
tabelindex MW een generalisatie van (SP, WN} en bovendien is WN zelf weer een genera- 
lisatie van {MP, NMP}. 


We willen er nog op wijzen dat er bij bilaterale verbindingseisen sprake is van een 
zogenaamd kip/ei-probleem: Een nieuwe dom(h)-waarde bestemd voor de M-tabel vraagt 
ook om een nieuwe mg(h)-waarde voor de D-tabel en... omgekeerd. Dit betekent dus dat 
er bij overgang naar een andere DB-toestand "in één keer" zowel een M-tupel als een D-tupel 
moet worden toegevoegd! Meer in het algemeen doet zich bij een DB-universum U over een 
DB-skelet g een kip/ei-situatie voor wanneer de volgende relatie cyclisch is: 


(M;D)e dom(g)xdom(g) | Ah e g(M) —& g(D) : h verbindt M permanent met D in U}, 


of, in woorden, de verzameling van alle indexparen (M ; D) waarvoor geldt dat M permanent 
wordt verbonden met D in U door een of andere attributentransformatie h. 
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OPGAVEN 
3.15. Geef de voorwaarden V14, V15 en V16 uit Voorbeeld 3.6 in woorden weer. 


3.16. Is de DB-toestand v2 uit Voorbeeld 3.2 een element van UBP uit Voorbeeld 3.6? 


3.17. Geef voor v e UBP in het kort de verschillen tussen de volgende tabellen weer. 
(a) v(BOM) >< v(PROD); 
(b) v(BOM) >< (v(PROD) eo h5); 
(c) v(BOM) >< v(PROD) >< (y(PROD) ee h5). 


3.18. Leg uit waarom UBP niet in 3NV is. 
3.19. Rond uw oplossingen bij de opgaven 3.0, 3.2, 3.8 en 3.14 af met de definitie van een 


bijbehorend DB-universum. 
oO 
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3.55 SAMENVATTING 

We hebben in de constructie van een DB-universum over een gegeven DB-skelet vier fasen 
onderscheiden. In elke fase worden er één of meer waardenverzamelingen gedefinieerd. We 


kunnen de onderlinge samenhang tussen die afzonderlijke "modules" in deze gefaseerde 
opbouw van de definitie van een DB-universum U als volgt schematisch weergeven: 


4e fase: 


WwW i jr wW 
on e T $ 
l 
T T = Dn T 
2e fase: i ; 
i 
i 


k 1 
le fase: Ee En I 
l i 


waarbij T; c II(F;) en 
W; c P(T;) en 
H = {((E1; W1), E2;W2),..., (En; W,)} en 
U < II(H) en 
waarbij [A] — [B ]betekent: A wordt gebruikt in de definitie van B. 


Mogelijk worden hierbij de definities van de objectkarakteriseringen F; tot en met F, nog 
voorafgegaan door de definities van enige hulpbegrippen (bijvoorbeeld constanten, ver- 
zamelingen of functies), zoals onder andere in de voorbeelden 2.13 en 3.6 en in §4.2. In 
database-kringen worden de hulpverzamelingen die als waardenverzamelingen voor 


SAMENVATTING 113 


attributen dienst doen (helaas) ook wel "domeinen" genoemd. Dit kan echter verwarring 
geven met de klassieke betekenis van het woord "domein", dat is het domein van een functie, 
of van een relatie in het algemeen (zie Hoofdstuk 0). 


We merken verder op dat deze hiërarchie van definities in (ten minste) twee verschillende 
volgorden is te presenteren: 


(A) Per tabelindex werkend, dat wil zeggen per tabelindex de resultaten van de fasen 1, 2 
en 3 direct achter elkaar presenteren. (Patroon: (F ; T ; W)*.) 


(B) Per fase werkend, dat wil zeggen eerst alle definities uit fase 1 presenteren, dan alle 
definities uit fase 2 en dan alle definities uit fase 3. (Patroon: F* ; T* ; W*.) 


Beiden gevallen eindigen met de definities van de DB-karakterisering H en (last but not 
least) het DB-universum U. 


We hebben volgorde (A) gebruikt in Voorbeeld 2.13 en §4.2. Volgorde (B) hebben we 
gebruikt in Voorbeeld 1.3, in het overzicht aan het eind van §2.4 (voor in wezen dezelfde 
definities als in Voorbeeld 2.13) en in het huidige hoofdstuk. In Hoofdstuk 8 zullen we de 
definities zelfs een paar keer "van achteren naar voren" presenteren (wat in dit verband ook 
wel top-down heet): we geven daar soms eerst de definitie van het DB-universum, daarna de 
definitie van de daarin genoemde database-karakterisering, daarna de definities van de daarin 
genoemde tabellenverzamelingen, enzovoort. 


Soortgelijke opmerkingen betreffende presentatievolgorden zijn overigens van toepassing op 
de te definiéren hulpbegrippen: in Voorbeeld 2.13 en in §2.4 staat elk hulpbegrip in feite 
direct vóór de (eerste) objectkarakterisering waarin het wordt gebruikt, terwijl in Voorbeeld 
3.6 en in §4.2 alle hulpbegrippen helemaal in het begin staan. 


We zullen laten zien dat de hierboven beschreven constructie inderdaad altijd een DB- 
universum oplevert, en wel over het DB-skelet g gedefinieerd door 
ee {(E; ;dom(F';)), (E2 ; dom(F2)), ...3 (En ; dom(F,))}: 


We beginnen met de opmerking dat F; een verzamelingsfunctie is. 

Daarom is niet alleen II(F;) maar ook elke deelverzameling T; van II(F;) een tabel 
over dom(F;), en dus over g(E;). 

Daarmee is niet alleen P(T;) maar ook elke deelverzameling W; van P(T;) een ver- 
zameling tabellen over g(E;). 

Nu volgt uit de eerder gegeven beschrijving van H dat elk element v van TI(H) een 
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functie over dom(g) is, en wel zodanig dat v(E;) voor elke E; in dom(g) een element 
van W; is. 

Uit de vorige twee conclusies volgt nu dat v(E;) een tabel over g(E;) is. 

Volgens Definitie 1.3 is nu II(H), en daarmee ook elke deelverzameling U van II(H), 
een DB-universum over g. 


Hiermee hebben we aangetoond dat op bovenstaande manier altijd een DB-universum wordt 
verkregen. (Dit geldt trouwens ook bij willekeurig veel tabelindexen en niet alleen bij een 
eindig aantal, zoals hierboven gesuggereerd.) In Opgave 3.22 wordt (impliciet) gevraagd aan 
te tonen dat, omgekeerd, elk DB-universum op deze manier kan worden beschreven. 


Een vraag die men zich na het definiëren van een DB-universum zeker zou moeten stellen, is 
de vraag of het zojuist gedefinieerde DB-universum wel consistent is, dat wil zeggen of het 
eigenlijk wel elementen bevat, zie Opgave 1.5. Immers, het zou kunnen dat de - in de prak- 
tijk vaak omvangrijke - definitie interne conflicten bevat zonder dat men zich dat meteen 
bewust is. Bovenstaande vraag zou (positief) beantwoord kunnen worden door een voor- 
beeld van een toestand te geven en aan te tonen dat het voorbeeld inderdaad aan alle in de 
definitie gestelde voorwaarden voldoet. 


Een toestand die men meestal als element van het te definiëren DB-universum over g wenst, 
is "de lege toestand" over de betreffende verzameling tabelindexen, dat wil zeggen de toe- 
stand AE e dom(g) : Ø ; deze toestand kan namelijk goed dienen als "starttoestand" (bij ini- 
tialisatie). Als men aantoont dat de lege toestand een element van het zojuist gedefinieerde 
DB-universum is, dan heeft men daarmee uiteraard ook de in de vorige alinea genoemde 
vraag meteen beantwoord (en wel in positieve zin). 


Als men weet dat een DB-universum U consistent is, dan rest nog de vraag of elke tabelin- 
dex E van U wel consistent in U is, dat wil zeggen of de E-tabel überhaupt wel ooit elemen- 
ten kan bevatten. (Volgens de in Opgave 1.5 geïntroduceerde terminologie is dit dan in feite 
de vraag of U regulier is.) Gewoonlijk kan deze vraag in positieve zin worden beantwoord 
door één toestand te geven waarin elke tabel niet-leeg is, en weer aan te tonen dat het voor- 
beeld inderdaad aan alle in de definitie gestelde voorwaarden voldoet. (Dat dit wel vol- 


doende maar niet altijd mogelijk is voor reguliere DB-universa blijkt uit één van de opgaven 
in Hoofdstuk 1.) 
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OPGAVEN 


3.20. Geef een "zo klein mogelijk" element van UBP uit Voorbeeld 3.6 waarin elke tabel 
niet-leeg is. 


3.21. Laat U een DB-universum over een verzamelingsfunctie g zijn. 


(a) Iser voor U een “kleinste” database-karakterisering? 
Zo ja, welke is het en in welke zin is de database-karakterisering het kleinst? 


(b) Iser voor elke tabelindex E van U een “kleinste” karakteriserende tupelverzame- 
ling? Zo ja, definieer dan deze verzameling tupels. 


(c) Iser voor elke tabelindex E van U een "kleinste" objectkarakterisering? 
Zo ja, welke is het en in welke zin is die objectkarakterisering het kleinst? 


3.22. Als U een DB-universum over een verzamelingsfunctie g is, dan is er voor elke tabelin- 
dex E van U een verzamelingsfunctie Fg zodanig dat U CTI(AE e He(U) : P(II(Fz))). 
Bewijs dit. 


4 EEN NIET-TRIVIAAL VOORBEELD VAN EEN 
DATABASE-UNIVERSUM 


In dit hoofdstuk presenteren we een niet-triviaal voorbeeld van een DB-universum om enig 
inzicht te geven in de praktische problemen die zich kunnen voordoen bij ontwerp en 
gebruik van complexe databases (dat wil zeggen databases met veel tabelindexen, zeg enige 
tientallen, veel attributen, zeg enige honderden in totaal, veel constraints, en veel relevante 
DB-functies, zeg ook enige tientallen). Naast massa (dat wil zeggen zeer veel tupels in de 
actuele toestand, zeg enige tienduizenden of enige miljoenen) is complexiteit een van de 
belangrijke bronnen van problemen bij databases zoals die in de praktijk voorkomen. 


Ons voorbeeld gaat over een (denkbeeldig) streekziekenhuis en is een variant op de voor- 
beelden in [Re 82] en [Br 84], onder meer uitgebreid met enige ideeén afkomstig uit [GOV 
84]. Er zijn 19 tabelindexen en in totaal 128 attributen. Verder zijn er in het voorbeeld vele 
soorten constraints (waaronder diverse zogeheten "business rules") verwerkt, afkomstig uit 
zeer uiteenlopende toepassingsgebieden (maar allemaal "vertaald" naar deze ene ziekenhuis- 
toepassing). Ook zijn er enige tientallen interessante DB-functies. 


De overwegingen bij het invullen van de details van het voorbeeld waren vooral van didac- 
tische en niet zozeer van medisch-organisatorische aard. Er is naar gestreefd de meeste soor- 
ten statische constraints die we in de praktijk zijn tegengekomen binnen één voorbeeld te 
laten zien, en niet om een voor ziekenhuizen zo geschikt mogelijke database-structuur te 
ontwerpen. 


Ook is er niet naar gestreefd het voorbeeld in andere (ontwerp)opzichten "optimaal" te 
maken; zo is het DB-universum bijvoorbeeld niet in de derde normaalvorm. Op deze wijze 
kan het voorbeeld tevens dienen om de consequenties van bepaalde ontwerpbeslissingen, 
bijvoorbeeld aanwezigheid van redundante gegevens, in de context van een complexe data- 
base te laten zien. 


Het hier geïntroduceerde voorbeeld is ook reeds enige malen gebruikt als "functional bench- 
mark" om bestaande database-managementsystemen op hun datadefinitiemogelijkheden te 
testen (zie [NGI 87], [NGI 88] en [IDT 881). 
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Van ons ziekenhuisvoorbeeld geven we in §4.1 een informele beschrijving en in §4.2 de for- 
mele definitie. Om het verband tussen de beide paragrafen gemakkelijk te kunnen aangeven 
hebben we sommige attribuutconstraints en alle tupel-, tabel- en database-constraints ge- 
nummerd (R01, R02, etcetera). De informele beschrijvingen zijn overigens niet altijd vol- 
doende scherp geformuleerd om daar de uiteindelijke formele definitie zonder meer uit te 
destilleren. Dit is echter representatief voor de gang van zaken in de praktijk. Vaak zal men 
dan ook nog eens naar de betreffende "materiedeskundige" terug moeten gaan om te vragen 
hoe het nu precies zit met die constraint. 


Tot besluit geven we in §4.3 enige voorbeelden van DB-functies over het in §4.2 
gedefinieerde DB-universum. 


4.1 INFORMELE BESCHRIJVING 


We beginnen de informele beschrijving van ons ziekenhuisvoorbeeld met een opsomming 
van de gebruikte tabelindexen en per tabelindex een korte omschrijving van de objecten die 
door de tupels van de bijbehorende tabel worden gerepresenteerd: 


[1] PAT : ingeschreven patiënten 

[2] MW : medewerkers (generalisatie van [3] en [4]) 
[3] SP : specialisten (ook vroegere) 

[4] WN : werknemers (generalisatie van [5] en [6]) 
[5] MP : medisch personeel 

[6] NMP : niet-medisch personeel 

[7] VV : verplicht verzekerde werknemers (differentiatie van [4]) 
[8] HA : huisartsen in de regio 

[9] PLR : plaatsen in de regio 

[10] AFD : afdelingen 

[11] RU : ruimten (ook vroegere en geplande) 

[12] OPN : opnamen (ook vroegere) 

[13] ONT : ontslagen 

[14] OSP : overdrachten (ook vroegere) 

[15] OVR : overplaatsingen (ook vroegere) 

[16] BEH : behandelingen 

[17]PB : (patiënt)behandelingen (ook vroegere) 
[18] MED : medicijnen 

[19] MVS : medicijnverstrekkingen (ook vroegere) 
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De bovengenoemde generalisaties geven een onderverdeling van medewerkers in specia- 
listen en werknemers en vervolgens van werknemers in medisch en niet-medisch personeel. 
Verder wordt met bovengenoemde differentiatie aangegeven dat sommige werknemers ver- 
plicht verzekerden zijn. Een en ander wordt schematisch weergegeven in Figuur 4.1. 


[2] [2] = [3] Y [4] en 


[3] A [4] =m 
[4] =[5] VU [6] en 

[5] A [6] =m 
[7] c [4] 


[5] ' [6] 


Figuur 4.1: Generalisatie en differentiatie 


We merken op dat deze gelijkheden en inclusies alleen gelden voor de betreffende verzame- 
lingen te representeren objecten maar niet, zoals straks zal blijken, voor de betreffende ver- 
zamelingen tupels! 


In elk van de volgende 19 alinea’s wordt telkens één van de tabellen nader toegelicht. 


Van alle ingeschreven patiënten moeten de volgende gegevens worden bijgehouden: 
patiëntnummer, NAW-gegevens (dat wil zeggen naam, adres, postcode en woon- 
plaats), geboorteplaats, geboortedatum, datum van inschrijving, bloedgroep, rhesus- 
factor, geslacht, (registratie)nummer van de huisarts, naam en praktijkadres van de 
huisarts en van de tandarts, naam en adres van de apotheek, verder van elk der kin- 
deren voornaam (roepnaam), geboortedatum en geslacht, en ten slotte een rubriek 
"diversen" voor allerlei andere wetenswaardigheden. Iedere ingeschreven patiënt heeft 
zijn (of haar) eigen patiëntnummer [R01] en per patiënt moet ieder kind een eigen RO1 
voornaam hebben [R02]. Een patiëntnummer moet een 6-cijferig getal zijn [RO3]. RO2,R 
Elk patiëntnummer moet bovendien deelbaar zijn door 9 [R04]. Het eerste cijfer van R04 
elk patiëntnummer kan op deze wijze worden opgevat als een controlecijfer, dit met 
het oog op eventuele fouten. (Ook in de praktijk komen dergelijke foutendetecterende 
codes voor maar ze zijn dan vaak subtieler van aard; een bekend voorbeeld is de 11- 
proef voor bankgironummers.) Ons ziekenhuis begon te draaien op 1 april 1960 en 
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daarom zal elke datum die betrekking heeft op een ziekenhuisactiviteit (waaronder 
ook inschrijfdatum) na 31 maart 1960 liggen [RO5]. Toen het ziekenhuis in 1960 
begon, kon een geboortedatum teruggaan tot 1850 [R06]. We merken verder op dat de 
inschrijfdatum niet vóór de geboortedatum van een ingeschreven patiënt mag liggen 
[R07]. Bovendien moet elke ingeschreven patiënt in de regio wonen [R08]. De 
betreffende huisarts zal een zogeheten "regio-arts" moeten zijn [RO9]. (Het begrip 
regio-arts zal verderop worden uitgelegd.) 


De volgende relevante gegevens zijn van toepassing op elke medewerker: identiteits- 
nummer (een getal van 3 of 4 cijfers), NAW-gegevens, afdelingsnummer, intern 
telefoonnummer (4-cijferig), soort medewerker (specialist, medisch personeel of niet- 
medisch personeel) en een rubriek "diversen". Het identiteitsnummer bepaalt de 
medewerker eenduidig [R10]. Elke medewerker is formeel verbonden aan een afde- 
ling van het ziekenhuis [R11]. Medewerkers met hetzelfde interne telefoonnummer 
moeten op dezelfde afdeling werken [R12]. 


Naast de algemene medewerkersgegevens zijn de volgende additionele kenmerken 
specifiek van toepassing op onze specialisten: identiteitsnummer van de zogeheten 
locum tenens (plaatsvervanger), soort dienstverband, specialismen (elke specialist 
moet één of meer specialismen hebben), telefoonnummer thuis, contractueel aantal 
uren per week (met een maximum van 50 uur), honorarium per uur (met een wettelijk 
minimum van 80 gulden) en aantal toegezegde bedden; ook moet worden bijgehouden 
of de specialist in kwestie nog steeds bij het ziekenhuis werkzaam is of niet. Dit 
laatste is nodig omdat we niet alleen de huidige specialisten bijhouden, maar ook alle 
vroegere specialisten (cumulatief dus). Als nadere toelichting op het aantal toe- 
gezegde bedden merken we op dat elke specialist op papier recht heeft op een bepaald 
aantal verpleegbedden; per specialist wordt dit aantal contractueel vastgelegd. (In het 
ziekenhuis spreken we in dit verband ook wel van “papieren bedden" omdat er geen 
“fysieke bedden" worden gereserveerd.) Het totale aantal toegezegde verpleegbedden 
mag echter het aantal daadwerkelijk aanwezige verpleegbedden met niet meer dan 
10% overschrijden [R13]. Voor specialisten die niet meer bij het ziekenhuis 
werkzaam zijn, stellen we het aantal toegezegde bedden op nul, evenals het aantal 
uren per week [R14]. Voor specialisten bestaat het identiteitsnummer uit drie cijfers. 
Elke specialist heeft, zijnde een medewerker, zijn eigen identiteitsnummer [R15]. 
Voor elke medewerker geeft het kenmerk “soort medewerker" precies aan of die 
medewerker een specialist is of niet [R16]. De plaatsvervanger van een specialist 
moet een andere [R17], (ooit) aan het ziekenhuis verbonden specialist zijn [R18]. (De 
voor de hand liggende eis dat de plaatsvervanger van een nog in dienst zijnde specia- 
list ook nog in dienst moet zijn, is de informatie-analisten van het ziekenhuis 
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kennelijk ontgaan; een andere reden kan zijn dat men de eis niet belangrijk genoeg 
vond om op te nemen.) 

We merken op dat de eisen R15 en R16 expliciet gesteld moeten worden om (samen 
met de onderstaande eisen R25 en R19) de eerstgenoemde generalisatie aan het begin 
van §4.1 formeel gestalte te kunnen geven. 


Onder een werknemer wordt (per definitie) verstaan een medewerker die niet als spe- 
cialist geboekt staat [R19]. Voor deze categorie medewerkers moeten de volgende 
extra gegevens worden bijgehouden: identiteitsnummer van de groepsleider, aantal 
halve (werk)dagen per week (omdat deelbetrekkingen mogelijk zijn), maandsalaris en 
aantal ziektedagen tot nu toe in het lopende jaar. Wegens de weekends en de feest- 
dagen kan het aantal ziektedagen (eigenlijk: verzuimde werkdagen) nooit meer dan 
290 bedragen. Het salaris kan hooguit gelijk zijn aan het ambtelijke maximumsalaris. 
Het ambtelijke maximumsalaris bedraagt momenteel 10720 gulden per maand [R20]. 
Bij een (deel)betrekking kan het salaris hooguit (een evenredig deel van) het amb- 
telijke maximumsalaris bedragen [R21]; het salaris mag echter niet beneden (het 
evenredige deel van) het ambtelijke minimumsalaris liggen [R22]. Het ambtelijke 
minimumsalaris bedraagt momenteel 975 gulden per maand [R23]. De voormalige 
werknemers worden niet bijgehouden; dus, anders dan bij specialisten, staan bij 
werknemers alleen de huidige geregistreerd. Alle werknemers moeten in de regio 
wonen [R24]. Voor werknemers bestaat het identiteitsnummer uit vier cijfers. Elke 
werknemer heeft, een medewerker zijnde, zijn eigen identiteitsnummer [R25]. Elke 
groepsleider is een werknemer die bovendien zichzelf formeel als groepsleider heeft 
[R26]. Groepsleiders mogen geen deeltijdbaan hebben [R27]. 


Tot het medische personeel behoren (per definitie) die medewerkers die als zodanig 
staan geboekt [R28]. (Specialisten worden dus blijkbaar niet tot het (gewone) 
medische personeel gerekend; tot het medische personeel kunnen alleen maar werkne- 
mers behoren.) Voor het medische personeel zijn naast de medewerkers- en werkne- 
mersgegevens ook het telefoonnummer thuis en de code van de (hoogste) vooroplei- 
ding van belang. Elk medisch personeelslid heeft, een medewerker zijnde, zijn eigen 
identiteitsnummer [R29]. 


R19 


R29 
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Tot het niet-medische personeel behoren per definitie die medewerkers die als 
zodanig staan geboekt [R30]. Voor het niet-medische personeel zijn naast de 
medewerkers- en werknemersgegevens ook de volgende drie gegevens relevant: func- 
tiecode, maandelijkse vergoedingsbedrag - hoewel een niet-medisch personeelslid 
diverse toeslagen en andere extra vergoedingen kan krijgen, houden we hier alleen het 
totale maandbedrag bij - en ten slotte het aantal vrije dagen per jaar waarop het betref- 
fende personeelslid recht heeft op basis van een volledige betrekking. Het maan- 
delijkse vergoedingsbedrag mag niet boven het maandsalaris uitkomen [R31]. Elk 
niet-medisch personeelslid heeft, zijnde een medewerker, zijn eigen identiteitsnummer 
[R32]. De eisen R32 en R30 dienen samen met de eisen R29 en R28 als expliciete 
weergave van de tweede generalisatie die aan het begin van §4.1 werd genoemd. 


Van alle verplicht verzekerde werknemers moeten de volgende extra gegevens wor- 
den bijgehouden: ziekenfondsnummer (8-cijferig), registratienummer van de huisarts 
en naam en adres van de apotheek. Elke genoemde verplicht verzekerde moet ook als 
werknemer geregistreerd staan [R33]. Daar elke werknemer in de regio moet wonen, 
zal ook de betreffende huisarts een regio-arts moeten zijn [R34]. Iedere verplicht 
verzekerde werknemer heeft niet alleen zijn eigen identiteitsnummer [R35] maar ook 
zijn eigen ziekenfondsnummer [R36]. De eisen R33 en R35 zijn nodig om de aan het 
begin van $4.1 genoemde differentiatie formeel gestalte te geven. 


In verband met bepaalde regionale (controle)taken die ons ziekenhuis heeft te vervul- 
len, is het noodzakelijk dat van alle huisartsen met een praktijk in de regio, de 
zogeheten "regio-artsen", de volgende gegevens worden bijgehouden: registratienum- 
mer, naam, praktijkadres - moet dus in de regio zijn [R37] - , telefoonnummer thuis en 
op de praktijk, spreekuurgegevens, aantal patiënten op 1 januari jongstleden (de vaste 
jaarlijkse peildatum), toename van het aantal patiënten in het afgelopen jaar en 
verwachte toename voor het lopende jaar. (Eventuele afname wordt genoteerd als 
negatieve toename.) Het registratienummer bepaalt de huisarts eenduidig [R38], 
evenals de combinatie van naam en praktijkadres [R39]. Uiteraard kan de toename 
van het aantal patiënten in het afgelopen jaar niet groter zijn dan het aantal patiënten 
op 1 januari jl. [R40]. Evenmin kan de eventueel verwachte afname in het lopende 
jaar groter zijn dan het aantal patiënten op 1 januari jl. [R41]. 


Eveneens in het kader van de door ons (streek)ziekenhuis te vervullen regionale con- 
troletaken dienen van alle plaatsen in de regio enige gegevens te worden 
bijgehouden, te weten de plaatsnaam (die binnen de regio uniek moet zijn [R42] ), het 
inwoneraantal (in duizendtallen), het aantal huisartsen, apotheken en tandartsen 
werkzaam in die plaats, naam en (praktijk)adres van de huisarts en van de apotheek 
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die voor die plaats het aanstaande weekend de weekenddienst waarnemen, en ten slot- 
te het identiteitsnummer van de aan ons ziekenhuis verbonden contactpersoon voor 
die plaats. Een contactpersoon is altijd een niet-medisch personeelslid [R43], meestal 
een maatschappelijk werker die de lokale situatie en problematiek goed kent. Voor 
plaatsen waarin ten minste vier huisartsen werkzaam zijn, moet de weekenddienst 
altijd worden waargenomen door een huisarts wiens praktijk gevestigd is in de betref- 
fende plaats zelf [R44]. In ieder geval moet de dienstdoende huisarts er een zijn met 
een praktijk in de regio [R45]. 


Van alle afdelingen van ons ziekenhuis moeten worden bijgehouden het afdelings- 
nummer, de afdelingsnaam, het identiteitsnummer van de chef en van de souschef - op 
sommige afdelingen ook wel hoofd en subhoofd genoemd - en de soort; er worden 
hierbij vijf soorten onderscheiden: medisch, administratief, laboratorium, dienst 
(waaronder bijvoorbeeld de centrale technische dienst en de dienst bouwzaken) en 
“diversen” [R46]. Elke afdeling heeft haar eigen nummer [R47] en haar eigen naam 
[R48]. De souschef van een afdeling moet een medewerker van die afdeling zijn 
[R49]. De chef van een afdeling moet ook een medewerker zijn [R50], maar niet 
noodzakelijk van dezelfde afdeling. (Zodoende kan iemand in principe chef van meer 
afdelingen zijn.) In geen enkele afdeling mogen de rollen van chef en souschef in 
dezelfde persoon zijn verenigd [R51]. Het is echter wel mogelijk dat iemand tegelijk 
souschef van de ene afdeling en chef van een andere afdeling is. Voor de rol van 
souschef komen alleen groepsleiders in aanmerking [R52]. 


Van alle actuele, vroegere en bij bestaande afdelingen nu reeds geplande ruimten 
moeten gegevens worden bijgehouden, en wel de volgende: ruimtenummer (bestaande 
uit een code van maximaal negen tekens), afdelingsnummer, vloeroppervlakte, status 
(aanwezig, gepland of vervallen), soort ruimte en aantal aanwezige bedden. Er worden 
vijf soorten ruimten onderscheiden: behandelruimten, verpleegruimten, recepties (en 
balies), magazijnen en "diversen" [R53]. Alle actuele, vroegere en geplande ruimten 
binnen ons ziekenhuis hebben hun eigen ruimtenummer [R54]. (De nummers van 
reeds vervallen ruimten mogen dus niet opnieuw worden gebruikt.) In een ruimte 
mogen maximaal 15 bedden staan. In elke ruimte moet er per bed ten minste vier vier- 
kante meter aan vloeroppervlakte zijn [R55]. In aanwezige behandelruimten en 
aanwezige verpleegruimten kunnen bedden staan, in andere ruimten echter niet [R56]. 
Daar afdelingen bij ons nooit vervallen, zullen alle aanwezige, vroegere en bij be- 
staande afdelingen reeds geplande ruimten altijd tot bestaande afdelingen moeten 
behoren [R57]. 
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Van alle lopende en reeds beéindigde opnamen moeten gegevens worden 
bijgehouden. Onder een opname wordt hier verstaan een aaneengesloten ver- 
blijfperiode van een patiént in het ziekenhuis. De volgende kenmerken zijn relevant 
voor elke opname: het nummer van de opgenomen patiént, de datum waarop de 
opname begon, het aanvankelijke ruimtenummer, het identiteitsnummer van de aan- 
vankelijk verantwoordelijke persoon, de aanvankelijke opnamereden, de naam en het 
praktijkadres van de huisarts op moment van opname, de dieetgegevens, de aan- 
vankelijke verpleegkundige bevindingen en de ontslagdatum (bij lopende opnamen de 
geplande vertrekdatum en bij reeds beëindigde opnamen de feitelijke vertrekdatum). 
Bij ruimtenummer en verpleegkundige bevindingen bedoelen we met aanvankelijk 
“tot eventuele overplaatsing naar een andere ruimte”, en bij verantwoordelijke persoon 
en opnamereden bedoelen we met aanvankelijk “tot eventuele overdracht van 
verantwoordelijkheid". Toelichting: Een patiënt kan gedurende een opname wel eens 
naar een andere ruimte worden overgeplaatst en, in principe onafhankelijk daarvan, 
ook wel eens onder de verantwoordelijkheid van iemand anders gaan vallen; hierop 
komen we later terug. 

Als afronding van onze opsomming van de relevante opnamegegevens merken we op 
dat bij elke opname ook nog moet worden aangegeven of die opname reeds is afgelo- 
pen en of de patiënt tijdens die opname is overleden. Als een patiënt overlijdt dan 
wordt de opname als beëindigd beschouwd [R58]. Opnamen duren in principe ten 
minste één nacht, maar overlijdensgevallen kunnen een uitzondering op deze regel 
vormen [R59]. Een patiënt kan per dag maar één keer worden opgenomen [R60]. 
Verschillende opnamen van een zelfde patiënt overlappen elkaar niet (hoewel de 
ontslagdatum van een opname wel de begindatum van de volgende opname kan zijn) 
[R61]. Per patiënt kan er ten hoogste één lopende opname zijn waarvoor dan alleen de 
opname met de meest recente begindatum in aanmerking komt [R62]. Een opname 
kan uiteraard alleen gevolgd worden door een andere opname van dezelfde patiënt als 
de betreffende patiënt tijdens de eerstgenoemde opname niet is overleden [R63]. Een 
opgenomen patiënt moet ingeschreven staan [R64] en een opname kan alleen maar 
plaatsvinden (of hebben plaatsgevonden) in één van de aanwezige of vroegere ver- 
pleegruimten [R65]. De aanvankelijk verantwoordelijke voor een opname moet altijd 
een van onze specialisten zijn [R66]. 
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Voor elke beeindigde opname zijn er twee extra kenmerken van belang, namelijk het 
factuurbedrag en de nazorginstructies. (Bij elk ontslag uit het ziekenhuis wordt er een 
factuur - ofwel rekening - opgemaakt, waarvan we hier alleen het eindbedrag bij- 
houden.) Voor een opname moet altijd minimaal 240 gulden in rekening worden 
gebracht. De genoemde extra kenmerken zijn voor elke beëindigde opname van 
toepassing en voor geen enkele lopende opname [R67]. Voor een zelfde patiënt 
kunnen er verscheidene beëindigde opnamen zijn, maar patiëntnummer plus opname- 
datum te zamen bepalen elke beëindigde opname eenduidig [R68]. Wat de sugges- 
tieve naamgeving al deed vermoeden is dankzij de eisen R67 en R68 nu ook expliciet 
weergegeven: de verzameling beëindigde opnamen vormt een differentiatie van de 
verzameling van alle opnamen. 


Zoals reeds eerder is opgemerkt, is het mogelijk dat gedurende een opname de 
verantwoordelijkheid voor die opname wordt overgedragen aan een andere specialist. 
Meestal gebeurt dit in verband met een nieuwe (opname)reden. We willen dan ook 
voor elke overdracht, dat wil zeggen elke verandering van verantwoordelijke specia- 
list, het nummer van de patiënt in kwestie, de datum van overdracht, het identiteits- 
nummer van de nieuwe specialist en de (eventueel nieuwe) opnamereden bijhouden. 
Een overdracht kan, administratief gezien, per patiënt ten hoogste één keer per dag 
plaatsvinden [R69]; de reden hiervoor is dat er toch maar één verandering relevant is 
wanneer een patiënt op een zelfde dag meer dan eens van verantwoordelijke specialist 
verandert. (Dit zal meestal de laatste verandering op die dag zijn.) Een overdracht kan 
bovendien alleen maar plaatsvinden tijdens een opname (van de betreffende patiënt) 
die op dat moment ten minste één nacht heeft geduurd [R70]. Evenals bij een opname 
moet ook bij een overdracht de nieuwe verantwoordelijke altijd een van onze specia- 
listen zijn [R71]. Het is mogelijk dat een patiënt gedurende een opname wordt 
overgeplaatst naar een andere ruimte. We willen van elke overplaatsing bijhouden het 
nummer van de patiënt die verhuist, de datum van overplaatsing, het nummer van de 
nieuwe ruimte en de nieuwe verpleegkundige bevindingen tijdens het verblijf in die 
nieuwe ruimte. Evenals een verandering van specialist kan, administratief gezien, een 
overplaatsing per patiënt ten hoogste één keer per dag plaatsvinden [R72] en wel 
alleen maar tijdens een opname (van de betreffende patiënt) die op dat moment ten 
minste één nacht heeft geduurd [R73]. Een overplaatsing kan alleen maar plaats- 
vinden (of hebben plaatsgevonden) naar één van de aanwezige of vroegere ver- 
pleegruimten [R74]. 


Van alle behandelingen die we kunnen uitvoeren, moeten de volgende gegevens wor- 
den bijgehouden: code, naam, soort, tarief, minimaal en maximaal verwachte duur, en 
ten slotte het geschatte aantal keren dat de behandeling in kwestie in het lopende jaar 
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zal worden uitgevoerd; deze prognose moet in het bijzonder een specificatie per 
maand geven. Zowel de code [R75] als de naam [R76] bepaalt de behandeling 
eenduidig. De maximaal verwachte duur mag uiteraard niet kleiner zijn dan de 
minimaal verwachte duur, maar eventueel wel gelijk daaraan [R77]. 


Van elke uitvoering van een behandeling houden we bij: het nummer van de behan- 
delde patiënt, de code van de uitgevoerde behandeling, het identiteitsnummer van de 
behandelende specialist (ook wel hoofdbehandelaar genoemd), het identiteitsnummer 
van de eventuele assistent-specialist (als er bij de behandeling geen assistent-specialist 
is, dan noteren we als assistent-specialist de hoofdbehandelaar zelf), het ruimtenum- 
mer, de behandelingsdatum, de feitelijke duur, het factuurbedrag en een volgnummer. 
Dit volgnummer wordt gebruikt om de verschillende toepassingen van een zelfde 
behandeling op dezelfde patiënt van elkaar te onderscheiden [R78]. Per patiënt 
worden de verschillende toepassingen van dezelfde behandeling opeenvolgend en 
chronologisch genummerd, te beginnen bij 1 [R79]. De hoofdbehandelaar moet altijd 
één van onze eigen specialisten zijn (geweest) [R80], en hetzelfde geldt voor de 
assistent-specialist [R81]. Verder moet de behandelde patiënt staan (of meteen 
worden) ingeschreven [R82] en tevens moet de uitgevoerde behandeling in ons 
“assortiment” voorkomen [R83]. Ten slotte merken we op dat een patiéntbehandeling 
alleen maar kan plaatsvinden (of hebben plaatsgevonden) in één van de aanwezige of 
vroegere behandelruimten [R84]. 


Ten behoeve van onze medische staf (dat wil zeggen specialisten plus medisch per- 
soneel) en onze eigen apotheek (zie de volgende alinea) moeten van diverse medi- 
cijnen enige gegevens worden bijgehouden, te weten de medicijncode, de naam, de 
soort, de gevarencode (die kan lopen van 1 t/m 20), de mogelijke bijwerkingen, het 
aantal eenheden in voorraad, de te berekenen prijs per eenheid en de voor die medicijn 
gebruikelijke eenheid. Afhankelijk van het geneesmiddel wordt de eenheid aangeduid 
met GR voor gram, MG voor milligram, ML voor milliliter - waarvoor echter bij som- 
mige medicijnen nog altijd CC wordt gebruikt - of ST voor stuks. Elk geneesmiddel 
heeft zowel zijn eigen medicijncode [R85] als zijn eigen naam [R86]. 


Ons ziekenhuis heeft een eigen apotheek die, op voorschrift van een specialist, medi- 
cijnen aan patiénten kan verstrekken. Van alle medicijnverstrekkingen tot nu toe 
moeten de volgende gegevens worden bijgehouden: patiëntnummer, medicijncode, 
datum van ingang, identiteitsnummer van de voorschrijvende specialist, voor- 
geschreven duur (met een maximum van 90 dagen), voorgeschreven aantal keren per 
dag (maximaal 6), voorgeschreven aantal eenheden per keer, factuurbedrag (minimaal 
een rijksdaalder) en een volgnummer. Dit volgnummer wordt gebruikt om de 
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verschillende medicijnverstrekkingen aan een zelfde patiént van elkaar te onder- 

scheiden [R87]. Per patiént worden de verschillende medicijnverstrekkingen R87 
opeenvolgend en chronologisch genummerd, te beginnen bij 1 [R88]. De voor- R88 
schrijvende specialist moet één van onze eigen specialisten zijn (geweest) [R89], de R89 
patiënt moet zijn ingeschreven [R90] en het voorgeschreven geneesmiddel moet bij R90 
onze apotheek bekend zijn [R91]. Tot besluit noemen we de randvoorwaarde dat onze R91 
ziekenhuisapotheek aan geen enkele patiënt hetzelfde geneesmiddel meer dan eens per 

dag mag verstrekken [R92]. R92 


De formele definities geven we in §4.2. Die paragraaf heeft de volgende (modulaire) 

opbouw: 

— De eerste pagina begint met de definities van enige “hulpconstanten" en "hulp- 
domeinen" (MINSAL tot en met KNDVZ). 


— Daama volgen er voor elk van de 19 “entiteiten”: 


— Een objectkarakterisering (FPAT, FMW, FSP, . . . , FMED, FMVS); hier komen 
we alleen attribuutconstraints tegen. 


— Eventueel nog een expliciet genoemde verzameling toegestane tupels (TPAT, 
TSP, .. . , TOPN, TBEH), namelijk voor die (negen) entiteiten waarvoor er 
tupelconstraints zijn. 


— De verzameling toegestane tabellen voor die entiteit (WPAT, WMW, WSP, ..., 
WMED, WMVS); hierin zijn de tabelconstraints verwerkt. 


— De voorlaatste pagina bevat de database-karakterisering FZKH, die de 19 tabelin- 
dexen introduceert en daaraan de bijbehorende verzameling toegestane tabellen toe- 
voegt. 


— Last but not least bevat de laatste pagina de definitie van ons DB-universum UZKH; 
hier treffen we alle databaseconstraints aan. 
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4.22 FORMELE DEFINITIE 


Definities 


MINSAL =975; 
MAXSAL = 10720; 


GBDVZ 
DATVZ 
RMSVZ 
SRTVZ 
PNRVZ 
TELVZ 


NAWVZ 


KTUVZ 


KNDVZ 


FPAT 


TPAT 


WPAT 


= [18500101 … 19991231]; 
= [ 600401 … 991231); 


= { ‘BHR’, ‘VPR’, ‘RCPT’, ‘MAG’, ‘DIV’); 
= {‘MED’, ‘ADM’, ‘LAB’, ‘DNST’, ‘DIV’}; 


= {k | ke Vng(6) en 

k mod 9 = 0}; 

= II((( NETN; [10 .. 9999}), 

( ABNR;; [100 .. 9999999) }); 


TI({( NM 


(ADR 


(PC 


(WPL 
TI(((VNM 


; Chs(20)), 
; Chs(20)), 
; Chs( 7)), 
; Chs(15))}); 
; Chs(14)), 


(GBD ;GBDVZ), 
(GESL ; {“M’, ‘V’})}); 
= {T | T c KTUVZ en 

{VNM} is u.i. in T}; 


{( PNR 
(NAW 
(GPL 
(GBD 
(INSD 
(BLGR 
(RHF 
(GESL 
(KNDG 
(NRHA 
(NAWH 
(NAWT 
(NAWA 
(DIV 


; PNRVZ), 

; NAWVZ), 

; Chs(15)), 

; GBDVZ), 

; DATVZ), 

{‘O’ ‘A? ‘B’ CAB’ }), 
UH, ~")), 


; [1 … 9999), 
; NAWVZ), 
‚ NAW VZ), 
; NAWVZ), 
; Chs(800))}; 


= (t | te II (FPAT) en 

t(GBD) < t((INSD) + 19000000}; 
= {T IT c TPAT en 

{PNR} is u.i. in T}; 
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Toelichting 


zie R23 

zie R20 

zie R06 

zie ROS 

zie R53 

zie R46 

zie R03 

zie R04 
netnummer (zonder de nul) 
abonneenummer 
naam 

adres 

postcode 
(woon)plaats 
voornaam 
geboortedatum 
geslacht 


zie RO2 


INGESCHREVEN PATIËNTEN: 
patiëntnummer 
NAW-gegevens 
geboorteplaats 

geboortedatum 

inschrijfdatum 

bloedgroep 

rhesusfactor 

geslacht 

gegevens der kinderen 
nummer van de huisarts 

naam en praktijkadres huisarts 
naam en praktijkadres tandarts 
naam en adres apotheek 
diversen 


zie R07 


zie R01 
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FMW = {(IDNR ; Vng(3) u Vng(4)), 


WMW 


FSP 


TSP 


WSP 


FWN 


TWN 


(NAW ;NAWVZ), 
(ANR ;[1.. 100]), 
(TELI ; Vng(4)), 
(SRTM ; { ‘SP’ , ‘MP’ , ‘NMP’ }), 
(DIV — ;Chs(1000))}; 
= {T |I T c (FMW) en 
{IDNR} is u.i. in T en 
{TELI} — {ANR} in 7}; 


= ((IDNR ; Vng(3)), 
(LOC  ; Vng(3)), 
(SDV ;Chs(15)), 
(SPEC ; P(Chs(15)) — {@}), 
(TELT ; TELVZ), 
( HONU ; [8000 ..)), 
(AUW ;[0.. 50), 
(ABD ; AN), 
(IND ; {JA NEE’ })}; 
= {t | ¢ e II (FSP) en 
t (LOC) + t (IDNR) en 
als t (IND) = ‘NEE’ 
dan (t (ABD) = 0 en t (AUW) = 0)}; 
= {T1T cTSPen 
{IDNR} is u.i. in T en 
{(LOC; IDNR)} verbindt T met 7}; 


= {(IDNR ; Vng(4)), 
(GLNR ; Vng(4)), 


(AHD  ;[1.. 10), 
(SAL ;[0.. MAXSAL]), 
(AZD_  ;[0_..290])}; 

= {t | t e II (FWN) en 


t (SAL)2 (MINSAL * t (AHD)) div 10 en 
t (SAL)< (MAXSAL * t (AHD)) div 10 en 


als t (IDNR) = t (GLNR) dan t (AHD) = 10}; 


WWN = {T IT c TWN en 


{IDNR} is u.i. in T en 
{(GLNR; IDNR)} verbindt T 
met (te T | t(GLNR) = t (IDNR) }}; 


MEDEWERKERS: 
identiteitsnummer 
NAW-gegevens 
afdelingsnummer 
telefoonnummer intern 
soort medewerker 
diversen 


zie R10 
zie R12 


SPECIALISTEN: 
identiteitsnummer 

id. nr. van de plaatsvervanger 

soort dienstverband 

specialismen 

telefoonnummer thuis 

honorarium per uur (in centen) 
aantal uren per week 

aantal toegezegde (verpleeg)bedden 
nog in dienst? 


zie R17 
zie R14 
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zie R15 
zie R18 


WERKNEMERS: 
identiteitsnummer 

id. nr. van de groepsleider 

aantal halve dagen per week 
maandsalaris (in guldens) 

aantal ziektedagen in het lopende jaar 


zie R22 
zie R21 
zie R27 


zie R25 
zie R26 
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FMP ={(IDNR ; Vng(4)), 
(TELT ; TELVZ), 
(OPLC ; Chs(8))}; 
WMP =({T1ITcII(FMP)en 
{IDNR} is u.i. in T}; 


FNMP ={(IDNR ; Vng(4)), 
(FCD ;Chs(10)), 
(AVD ;[15.. 30); 
( VERG ; N)}; 
WNMP = {T IT c II (FNMP) en 
{IDNR} is u.i. in T}; 


FVV ={(IDNR ; Vng(4)), 
(ZENR ; Vng(8)), 
( NRHA ; [1 … 99991), 
( NAWA; NAWVZ)}; 
WVV ={T IT cII (FVV) en 
{IDNR} is u.i. in T en 
(ZENR} is u.i. in 7}; 


FHA = {( NRHA ; [1..9999]), 
( NAWH; NAWVZ), 
( TELP ;TELVZ), 
(TELT ;TELVZ), 
(SPRU ;Chs(25)), 
(PAT ; AN), 
(TOEN ; Z), 
( VWTN; Z)}; 

THA = {t |t e II (FHA)en 


t(PAT) - t (TOEN) 2 0 en 
t(PAT) + t (VWTN) 2 0}; 


WHA ={T IT c THA en 
{NRHA} is u.i. in T en 
{NAWH} is u.i. in T}; 
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MEDISCH PERSONEEL: 
identiteitsnummer 
telefoonnummer thuis 
vooropleidingscode 


zie R29 


NIET-MEDISCH PERSONEEL: 
identiteitsnummer 

functiecode 

aantal vrije dagen per jaar 
vergoedingsbedrag (in guldens) 


zie R32 


VERPLICHT VERZEKERDEN: 
identiteitsnummer 
ziekenfondsnummer 

nummer van de huisarts 

naam en adres apotheek 


zie R35 
zie R36 


HUISARTSEN IN DE REGIO: 
nummer van de huisarts 

naam en praktijkadres 
telefoonnummer praktijk 
telefoonnummer thuis 

spreekuur 

aantal patiënten op 1 januari jl. 
patiëntentoename vorig jaar 
verwachte toename dit jaar 


zie R40 
zie R41 


zie R38 
zie R39 
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FPLR = {( WPL. ;Chs(15), 
(INWA; [0 .. 1000]), 
(CPRS ; Vng(4)), 

( DDHA; NAWVZ), 

( DDAP; NAWVZ), 

(AHA ; IN), 

(AAP ; N), 

(ATA ; N); 
= {t | te II (FPLR) en 

als t (AHA) 2 4 
dan t (DDHA) (WPL) = t (WPL)}; 
WPLR = {T I T c TPLR en 
{WPL} is u.i. in T}; 


TPLR 


FAFD =((ANR ;[1.. 100)), 
( ANM ; Chs(20)), 
( CHNR; Vng(4) U Vng(3)), 
( SCNR ; Vng(4)), 
(SRT ;SRTVZ)); 
TAFD = {t |¢ e II (AFD) en ((CHNR) # t (SCNR)}; 
WAFD = {T I T c TAFD en 
(ANR) is u.i. in T en 
{ANM} is u.i. in T}; 


FRU ={(RNR_ ;Chs(9)), 
(ANR ;[1..100)]), 
(OPVL ; N), 
(STAT ; {‘AANW’ , “GEPL’ , ‘VERV’ }), 
(SRTR ; RMSVZ), 
(ABD ;[0.. 15))); 
= {tlte II (FRU) en 
t (OPVL) = 4 * t (ABD) en 
als £(ABD) #0 
dan t (STAT) = ‘AANW’ en 
t (SRTR) €e { ‘BHR’, ‘VPR’}}; 
={({T IT <TRUen 
{RNR} is u.i. in 7}; 


TRU 


WRU 


PLAATSEN IN DE REGIO: 
plaatsnaam 

inwoneraantal (in duizendtallen) 

id. nr. contactpersoon 

dienstdoende huisarts a.s. weekend 
dienstdoende apotheek a.s. weekend 
aantal huisartsen werkzaam in die plaats 
aantal apotheken in die plaats 

aantal tandartsen werkzaam in die plaats 


zie R44 


29 


zie R42 


AFDELINGEN: 
afdelingsnummer 
afdelingsnaam 

id. nr. van de chef 

id. nr. van de souschef 
soort afdeling 

zie R51 


zie R47 
zie R48 


RUIMTEN: 
ruimtenummer 
afdelingsnummer 
oppervlakte (in m?) 
status 

soort ruimte 

aantal aanwezige bedden 


zie R55 
zie R56 


9 


zie R54 


FORMELE DEFINITIE 


FOPN ={(PNR ;PNRVZ), 
(OPND ; DATVZ), 
(RNR ; Chs(9)), 
(IDNR ; Vng(3)), 
(OPNR ; Chs(40)), 
(NAWH; NAW VZ), 
(DGEG ; Chs(240)), 
(BEV ;Chs(1200)), 
(ONTD ; DATVZ), 
(ONTS ; { ‘JA’, NEE’ }), 
(OVRL ; { ‘JA’, ‘NEE’ })}; 
TOPN = (tte II (FOPN) en (OPND) < ((ONTD) en 
(als (OPND) = ((ONTD) dan ((OVRL) = ‘JA’ ) en 
(als (OVRL) = ‘JA’ dan (ONTS) = “JA’)}; 
WOPN = {T IT c TOPN en 
{ PNR, OPND} is u.i. in T en 
VteT:Vt'eT:als t (PNR) = (PNR) en 
t (OPND) < t’(OPND) 
dan t (ONTD) < t’ (OPND) en 
t (ONTS) = ‘JA’ en 
t (OVRL) = ‘NEE’ }; 


FONT ={(PNR ;PNRVZ), 
(OPND ; DATVZ), 
( BEDR ; [24000.. )), 
( NZRG ; Chs(160))}; 
WONT = {T IT cII (FONT) en 
{PNR, OPND} is u.i. in T}; 


FOSP ={(PNR_ ;PNRVZ), 
(BDAT ; DATVZ), 
(IDNR ; Vng(3)), 
(OPNR ; Chs(40))}; 
WOSP = {T |T € II (FOSP) en 
{ PNR, BDAT} is u.i. in 7}; 
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OPNAMEN: 

patiéntnummer 
opnamedatum 
verpleegruimtenummer 

id. nr. verantwoordel. specialist 
opnamereden 

toenmalige huisarts 
dieetgegevens 
verpleegkundige bevindingen 
(geplande) ontslagdatum 
ontslagen? 

overleden? 

zie R59 


29 


zie R58 


zie R60 


zie R61 
zie R62 
zie R63 


ONTSLAGEN: 
patiëntnummer 
opnamedatum 
factuurbedrag (in centen) 
nazorginstructies 


zie R68 


OVERDRACHTEN: 
patiëntnummer 

datum van overdracht 
id. nr. nieuwe specialist 
(nieuwe) opnamereden 


zie R69 
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FOVR ={(PNR ;PNRVZ), 
( BDAT ; DATVZ), 
(RNR ;Chs(9)), 
(BEV ;Chs(400))}; 
WOVR = {T | T II (FOVR) en 
{ PNR, BDAT} is u.i. in T}; 


FBEH ={(BCD ;Chs(4)), 
(BNM ; Chs(50)), 
(BSRT ; Chs(3)), 
(TAR ;[10..)), 
(MIND ; [1 ..)), 
( MAXD, [1 ..)), 
(PRGN ; [1 … 12] > IN)}; 


TBEH = {t | t e II (FBEH) en t (MIND) < t(MAXD)}; 


WBEH = {T I T c TBEH en 
{BCD} is u.i. in T en 
{BNM} is u.i. in 7}; 


FPB ={(PNR ;PNRVZ), 
(BCD ;Chs(4)), 
(VNR ;[1..)), 
(IDNR ; Vng(3)), 
( ASNR ; Vng(3)), 
(RNR ; Chs(9)), 
( BDAT ; DATVZ), 
(DUUR; [1 ..)), 
( BEDR ; [1000 ..))}; 
WPB =({T1TcII (FPB)en 
{ PNR, BCD, VNR} is u.i. in T en 
VteT: alst(VNR) #1 


dan 3t’e T : t’} (PNR, BCD} =f} (PNR, BCD} 


en t’ (VNR) =t (VNR) - 1 
en t’ (BDAT) < t (BDAT)}; 


OVERPLAATSINGEN: 
patiëntnummer 

datum van overplaatsing 
nieuw verpleegruimtenummer 
additionele bevindingen 


zie R72 


BEHANDELINGEN: 
behandelcode 

behandelnaam 

behandelsoort 

tarief (in guldens) 

min. verwachte duur (in minuten) 
max. verwachte duur (in minuten) 
jaarprognose maandelijks aanbod 
zie R77 


zie R75 
zie R76 


PATIËNTBEHANDELINGEN: 
patiëntnummer 

behandelcode 

volgnummer 

id. nr. behandelende specialist 

id. nr. assistent-specialist 

nr. van de behandelruimte 
behandelingsdatum 

duur (in minuten) 

factuurbedrag (in centen) 


zie R78 
zie R79 


= {(PNR 


FORMELE DEFINITIE 


FMED ={(MCD ;Chs(6)), 


(MNM  ; Chs(20)), 

(MSRT ; Chs(4)), 

(GVC ;[1..20)), 

(BIW ;P(Chs(15))), 

(VRD ; N), 

(EENH ; {‘GR’, ‘MG’, ‘ML’, ‘CC’, ‘ST’}), 
(VKPR ; AN}; 


WMED = {T IT CIT (FMED) en 


{MCD} is u.i. in T en 
{MNM} is u.i. in T}; 


; PNRVZ), 
; Chs(6)), 
; DATVZ), 
(VNR ;[1..)), 
(IDNR ; Vng(3)), 
(DUUR ; [1 … 90)), 
(FREQ ; [1 …6)), 
(AEK ;[1…)), 
(BEDR ; [250..))}; 


(MCD 
(DAT 


WMVS = {T IT e II (FMVS) en 


{ PNR, MCD, DAT} is u.i. in T en 

{ PNR, VNR} is u.i. in T en 

VteT: als t (VNR) #1 

dan 3t’e T : t’ (PNR) = t (PNR) en 
t’ (VNR) = t (VNR) — 1 en 
t’ (DAT) < t (DAT)}; 
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MEDICIJNEN: 
medicijncode 
medicijnnaam 
medicijnsoort 

gevarencode 

mogelijke bijwerkingen 
aantal eenheden in voorraad 
eenheid | 

prijs per eenheid (in centen) 


zie R85 
zie R86 


MEDICIJNVERSTREKKINGEN: 
patiëntnummer 

medicijncode 

datum van ingang 

volgnummer 

id. nr. voorschrijvende specialist 
voorgeschreven duur (in dagen) 
frequentie per dag 

aantal eenheden per keer 
factuurbedrag (in centen) 


zie R92 
zie R87 
zie R88 


EEN NIET-TRIVIAAL VOORBEELD VAN EEN DATABASE-UNIVERSUM 


FZKH = {(PAT ; WPAT), 


(MW ;WMW), 
(SP ; WSP), 
(WN ;WWN), 
(MP ; WMP), 
(NMP ; WNMP), 
(VV ;WVV), 
(HA ; WHA), 
(PLR ; WPLR), 
(AFD ;WAFD), 
(RU ; WRU), 
(OPN ; WOPN), 
(ONT ; WONT), 
(OSP ; WOSP), 
(OVR ; WOVR), 
(BEH ; WBEH), 
(PB ; WPB), 
(MED ; WMED), 


(MVS ; WMVS)}; 


ingeschreven patiénten 
medewerkers 

specialisten (ook vroegere) 
werknemers 

medisch personeel 

niet-medisch personeel 

verplicht verzekerde werknemers 
huisartsen in de regio 

plaatsen in de regio 

afdelingen 

ruimten (ook vroegere en geplande) 
opnamen (ook vroegere) 

ontslagen 

overdrachten (ook vroegere) 
overplaatsingen (ook vroegere) 
behandelingen 

patiéntbehandelingen (ook vroegere) 
medicijnen 

medicijnverstrekkingen (ook vroegere) 
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UZKH = {vl ve II (FZKH) en 


id({PNR}) verbindt v(OPN) met v(PAT) en zie R64 
id({PNR}) verbindt v(PB) met v(PAT) en zie R82 
id({PNR}) verbindt v(MVS) met v(PAT) en zie R90 
{(SCNR; IDNR), (ANR; ANR)} verbindt (AFD) met v(MW) en zie R49 
{(CHNR; IDNR)} verbindt v(AFD) met MW) en zie R50 
{(ASNR; IDNR)} verbindt (PB) met v(SP) en zie R81 
id({ IDNR }) verbindt v(PB) met v(SP) en zie R80 
id({IDNR}) verbindt v(OPN) met v(SP) en zie R66 
id({IDNR }) verbindt v(OSP) met v(SP) en zie R71 
id({IDNR }) verbindt v(MVS) met v(SP) en zie R89 
id({IDNR}) verbindt v(VV) met v(WN) en zie R33 
{(SCNR; GLNR)} verbindt v(AFD) met v(WN) en zie R52 
{(CPRS; IDNR)} verbindt v(PLR) met v(NMP) en zie R43 
{(DDHA; NAWH)} verbindt v(PLR) met v(HA) en zie R45 
id({NRHA, NAWH}) verbindt v(PAT) met v(HA) en zie R09 
id({ NRHA}) verbindt v(VV) met v(HA) en zie R34 
id({ ANR}) verbindt v(MW) met v(AFD) en zie R11 
id({ ANR}) verbindt v(RU) met v(AFD) en zie R57 
id({BCD}) verbindt v(PB) met v(BEH) en zie R83 
id({MCD}) verbindt v(MVS) met v(MED) en zie R91 
id({RNR}) verbindt 

v(OPN) met {t e v(RU) | (STAT) + ‘GEPL’ en (SRTR) = ‘VPR’ }, zie R65 


v(OVR) met {t e v(RU) | (STAT) + ‘GEPL’ en (SRTR)= ‘VPR’ }en | zie R74 
v(PB) met (te v(RU) | (STAT) + ‘GEPL’ en (SRTR) = ‘BHR’},en | zie R84 


id({WPL}) verbindt 
{t(NAW) | t € (MW) en (SRTM) # ‘SP’ } met v(PLR), zie R24 
(NAW) | t € v(PAT)} met v(PLR) en zie R08 
{t(NAWH) |t e v(HA)} met v(PLR), en zie R37 
id({IDNR}) verbindt 
v(SP) bilateraal met {t € v(MW) | (SRTM) = ‘SP’ }, zie R16 
v(WN) bilateraal met {t e v(MW) | (SRTM) + ‘SP’ }, zie R19 
v(MP) bilateraal met {t € v(MW) | (SRTM) = ‘MP’ } en zie R28 
v(NMP) bilateraal met {t € v(MW) | (SRTM) = ‘NMP’ }, en zie R30 
id({PNR, OPND}) verbindt | 
v(ONT) bilateraal met {t € v(OPN) | (ONTS) = ‘JA’ } en zie R67 
(Dt € (SP) : (ABD)) S zie R13 
(11/10) * (Sit € v(RU) en (SRTR) = “VPR? : (ABD) en ” 
(Vt € (NMP) >< v(WN) : (VERG) < (SAL) en zie R31 
(Vt e v(OSP) U KOVR): St’ € OPN): zie R70 en R73 


(t’(PNR) = t(PNR) en t’(OPND) < t((BDAT) en 
als t’(ONTS) = ‘JA’ dan t((BDAT) < t’(ONTD)))}. 


29 


thd 
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OPGAVEN 


4.1. (a) 
(b) 


Is "de lege toestand” toegestaan? (M.a.w. (AE e He (UZKH): Ø) e UZKH?) 


Zij UZKH2 het DB-universum gedefinieerd door in de definitie van UZKH het 
"S"-teken in R13 te vervangen door het "<"-teken. Is "de lege toestand" in 
UZKH2 toegestaan? 


4.2. Zij GZKH het DB-skelet waarover het DB-universum UZKH is gedefinieerd. 


(a) 
(b) 


Schrijf dom (GZKH) uit. 
Schrijf GZKH (MW) uit. 


4.3. Ga voor elk van de volgende beweringen de geldigheid (en eventueel zelfs de zin- 
ledigheid) in UZKH na. Noem voor elke geldige bewering de constraint(s) waaruit de 
bewering volgt. Geef voor elke niet altijd geldige of zinledige bewering kort en 
duidelijk aan welke veranderingen in de definitie van het DB-universum nodig zijn om 
alsnog aan het gestelde te kunnen voldoen. 


(a) 


(b) 
(c) 
(d) 
(e) 
(f) 
(g) 
(h) 
(i) 
0, 
(k) 
(1) 
(m) 


(n) 


(0) 


Eenzelfde behandeling kan op eenzelfde datum op eenzelfde patient niet meer 
dan éénmaal plaatsvinden. 

Voor behandelsoort KNO geldt een vast tarief van 40 gulden. 

Voor elke behandelsoort geldt een eigen vast tarief. 

Afdeling 9 heeft minstens twintig medewerkers. 

Afdeling 1 heeft minstens twintig medewerksters. 

Afdeling 7 heeft minstens twintig werkneemsters. 

De afdeling neurologie heeft minstens vijf werkneemsters. 

Een specialist kan tot meer dan één afdeling behoren. 

Een specialist voor nul uren in de week is niet meer in dienst. 

Een specialist met toegezegde bedden is nog in dienst. 

Een patiënt kan voor meer dan één reden worden opgenomen. 

Alleen de "lopende" opnamen worden bijgehouden. 

Een patiënt is iemand die een opname, een behandeling of een medicijnverstrek- 
king heeft ondergaan. 

Het tarief van een behandeling ligt vast door de combinatie van behandelcode en 
behandelend specialist. 

Het tarief van een behandeling ligt vast door de combinatie van behandelsoort en 
behandelend specialist. 
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(p) 
(q) 
(r) 
(s) 
(t) 
(u) 
(v) 
(w) 
(x) 


(y) 


(z) 


Er kan worden nagegaan of een specialist actief is geweest. 

Een medewerker kan tevens een patiënt zijn. 

Per medicijnverstrekking ligt de totaal verstrekte hoeveelheid vast. 

Elke behandeling vindt plaats tijdens een opname. 

Niemand is contactpersoon voor twee of meer plaatsen tegelijk. 

Een contactpersoon voor een plaats in de regio moet ook in die plaats wonen. 

Een specialist kan tevens groepsleider zijn. 

Niemand kan chef van meer dan één afdeling zijn. 

De hoofdbehandelaar en de assistent-specialist bij een patiëntbehandeling zijn 
altijd aan dezelfde afdeling verbonden. 

Een patiëntbehandeling vindt altijd plaats in de afdeling waaraan de hoofdbehan- 
delaar is verbonden. 

Op elke verpleegruimte zijn er niet meer lopende opnamen dan er zich bedden in 
die verpleegruimte bevinden. 


4.4. Is (v(PAT) | v e UZKH} in BCNF of in 3NF? 
(U mag er hierbij van uitgaan dat Ms ({v(PAT) | v e UZKH}) = {{PNR}}.) 


4.5. Levert toevoeging van een willekeurig specialisttupel t aan "de lege toestand" weer een 
"correcte" DB-toestand (dat wil zeggen een element van UZKH) op? 
Zo niet, schets dan de eisen aan de andere tupels die er minimaal moeten worden toe- 
gevoegd om een correcte DB-toestand te verkrijgen. 


4.6. Wanneer we twee volgens UZKH "correcte" toestanden bij elkaar voegen, krijgen we 
dan weer een correcte toestand? Formeler verwoord luidt de vraag: 
Vve UZKH: Vv’ e UZKH: (AE e He(UZKH) : v(E) U v'(E)) €e UZKH? 


4.3 ENIGE DATABASE-FUNCTIES 


In deze paragraaf definiëren we een 34-tal relevante DB-functies over UZKH. Op één uit- 
zondering na is hierbij de naam van een DB-functie met betrekking tot een geordend paar 
tabelindexen (a; B) van de vorm "Haß". 
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Hspsp 
Hwnwn 
Hopnpat 
Hpbpat 
Hmvspat 
Hafdmw 
Hpbsp 
Hpbspa 
Hopnsp 
Hospsp 
Hmvssp 
Hvvwn 
Hplrnmp 
Hplrha 
Hpatha 
Hvvha 
Hmwafd 
Hruafd 
Hpbbeh 
Hmvsmed 
Hopnru 
Hovrru 
Hpbru 
Hspmw 
Hwnmw 


Hmpwn 
Hnmpwn 
Hafdwn 
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Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 
Ave UZKH: 


Ave UZKH: 
= Ave UZKH: 


Ave UZKH: 


Ave UZKH: 


{(¢; 
{(t; 
{(t; 
‚u) € v(PB) 
;u) € v(MVS) x v(PAT) 
;u) € (AFD) x v(MW) 
;U) € v(PB) 
;u) € v(PB) 
{(¢; 
{(t; 
;u) € v(MVS) x v(SP) 
‚u)e v(VV) 
{(t; 
{(t; 
‚u) € WPAT) 
;‚u)E v(VV) 

‚u) Ee (MW) 
;u) € v(RU) 

;u) € v(PB) 

{(t; 
;u)€ KOPN) x (RU) 
;u)€ KOVR) x (RU) 
;u) € v(PB) 
{(t; 
{(t; 


(C 
(C 
(( 
(C 
(C 


(C 
{(¢¢ 


{(¢ 
{(¢ 
{(¢ 
{(¢ 
{(¢ 


(C 
(C 
((t 


(C 
(G 
(C 


u) e v(SP) x v(SP) 

u)e (WN) x WWN) 
u) e v(OPN) x v(PAT) 
x (PAT) 


x v(SP) 
x V(SP) 
u) e (OPN) x v(SP) 
u) e v(OSP) x v(SP) 


x (WN) 
x (NMP) 
x WHA) 
x (HA) 
x WHA) 
x (AFD) 
x (AFD) 
x V(BEH) 
u) e v(MVS) x v(MED) 


u) € v(PLR) 
u) € v(PLR) 


x v(RU) 
x (MW) 
x (MW) 


u) € (SP) 
u) € v(WN) 


su) E (MP) Xv(WN) 
;u) € WNMP) x v(WN) 
;u) Ee (AFD) x v(WN) 


Hontopn = Ave UZKH: 


Hpatplr = Ave UZKH 
Hhaplr = Ave UZKH 


Hwnplr = Ave UZKH: 


Hospopn = Ave UZKH: 


Hovropn = Ave UZKH: 


(C 


;u) € WONT) x v(OPN) 


;u)€ (PAT) X v(PLR) 
u) Ee WHA) Xv(PLR) 


4) € (WN) X v(PLR) 


;u)€ (OSP) x v(OPN) 


;u) E (OVR) x v(OPN) 


| (LOC) = u(IDNR)} 
| «GLNR) = u(IDNR)} 
| (PNR) = u(PNR)} 

| (PNR) = u(PNR)} 

| (PNR) = u(PNR)} 

| «CHNR) = u(IDNR)} 
| IDNR) = u(IDNR)} 
| «ASNR) = u(IDNR)} 
| IDNR) = u(IDNR)} 
| (IDNR) = u(IDNR)} 
| IDNR) = u(IDNR)} 
| IDNR) = u(IDNR)} 
| «CPRS) = u(IDNR)} 
| {DDHA) = u(NAWH)} 
| (NRHA) = u(NRHA)) 
| (NRHA) = u(NRHA)) 
| ANR) = u(ANR)} 
| (ANR) = u(ANR)} 
| (BCD) = u(BCD)} 

| «MCD) = u(MCD)} 
| RNR) = u(RNR)} 
| (RNR) = u(RNR)} 
| (RNR) = u(RNR)} 
| «<IDNR) = u(IDNR)} 
| (IDNR) = u(IDNR)} 
| (IDNR) = u(IDNR)} 
| IDNR) = u(IDNR)} 


| (SCNR) = u(IDNR)} 
t} (PNR, OPND} = u | (PNR, OPND}} 


(NAW) (WPL) = u(WPL)} 
((NAWH) (WPL) = u(WPL)} 


Jm e v(MW): m(IDNR) = t(IDNR) en 
m(NAW) (WPL) = u(WPL)} 


t(PNR) = u(PNR) en u(OPND) < t(BDAT) en 
als u(ONTS) = ‘JA’ dan (BDAT)< u(ONTD 
t(PNR) = u(PNR) en u(OPND) < ((BDAT) en 
als u(ONTS) = ‘JA’ dan (BDAT)< u(ONTD 
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De onderstaande figuur geeft voor elk van de zojuist gedefinieerde DB-functies H aan hoe de 
functie H(v) in toestand v "loopt". Gezien de systematische naamgeving voor deze DB- 
functies bevat deze figuur (in tegenstelling tot Figuur 2.11) niet de namen van de betreffende 
DB-functies maar de belangrijkste constraints voor het bestaan van die functies. De in 
Opgave 4.9 genoemde injectieve functies zijn gerepresenteerd door een "vette" pijl. 


v(PAT) 
v(ONT) 


N 
5 60 


R67 


v(RU) 


Figuur 4.2 
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OPGAVEN 


4.7. 


4.8. 


4.9. 


4.10. 


4.11. 


4.12. 


Bewijs de zojuist gedefinieerde functies inderdaad DB-functies over UZKH zijn. (We 
merken hierbij op dat we deze 34 functies door middel van lege regels in zes groepen 
hebben verdeeld, en wel op grond van de nu te geven bewijsvoeringen.) 


Zij Hpatha2 = 7 v e UZKH: ((t; u) € v(PAT) x v(HA) | (NAWH) = u(NAWH)}. 
Bewijs dat Hpatha2 = Hpatha. 


Bewijs dat voor elke v e UZKH de volgende functies injectief zijn: 
Hafdwn(v), Hmpwn(v), Hnmpwn(v), Hontopn(v), Hspmw(v), Hvvwn(v), Hwnmw(y). 


Geef een formele definitie van de DB-functie over UZKH die in elke toestand aan elk 
tupel van een verplicht verzekerde werknemer het tupel van diens woonplaats toevoegt 
en bewijs dat deze functie inderdaad een DB-functie over UZKH is. 


Geef, uitgaande van een DB-toestand v e UZKH, de volgende verzamelingen in woor- 
den weer: 


(a) ((v(@B) | (PNR, BDAT}) >< v(OVR)) | {PNR}) >< mg(Hmvspat(y)). 
(b) {t | te v(WN) en (GLNR) = (IDNR)} | {IDNR} 

— (Y(WN) Pa v(VV)) ee ((IDNR; GLNR)}. 
(c) ((v(PB) eo ((LOC; ASNR), (IDNR; IDNR)}) >< v(SP) | {IDNR}. 


Onder BMD(v,t), het (beknopte) medische dossier van een patiénttupel t in DB- 
toestand v € UZKH, verstaan we een functie over (ALGGEG, MVSGEG, PBHGEG, 
OPNGEG} met als waarden (achtereenvolgens) 


— het betreffende patiënttupel "uitgebreid" met de (twee) telefoonnummers van de 
huisarts van die patiént, 


— van alle medicijnverstrekkingen aan die patiënt: medicijncode, ingangsdatum, 
frequentie per dag en aantal eenheden per keer, 


— van alle behandelingen van die patiënt: behandelcode en -naam, volgnummer, 
behandelingsdatum en het identiteitsnummer van de behandelende specialist, 


— van alle beëindigde opnamen van die patiënt: opnamedatum, ontslagdatum en 
opnamereden. 
Geef een formele definitie van BMD(v, ñ). 


5 DYNAMISCHE CONSTRAINTS 


5.1 TRANSITIERELATIES 


Met de keuze van een DB-universum U willen we vastleggen welke toestanden in een orga- 
nisatie formeel zijn toegestaan. In het algemeen echter zijn niet alle toestandsovergangen 
(alias transities) tussen die op zich toegestane toestanden geoorloofd in die organisatie. We 
kunnen nu de verzameling toegestane transities vastleggen door middel van een deelver- 
zameling R van U x U met als intuitieve betekenis: 


(v; v’) e R <> de directe overgang van toestand v naar toestand v’ is toegestaan. 


Als (v ; v’) R dan kan het nog wel zo zijn dat v’ indirect vanuit v te bereiken is, namelijk 
als (v; v’) € Tcl(R), dat willen zeggen als v’ via een aantal toegestane tussenstappen te 
bereiken is vanuit v (zie Definitie 0.22). 


Een element van U x U noemen we een transitie binnen U en een verzameling toegestane 
transities behorende bij het DB-universum U noemen we wel een transitierelatie op U. Meer 
in het algemeen: | 


DEFINITIE 5.1: 
Als U een verzameling is, dan: 


(a) pis een transitie binnen U & pe UxU; 


(b) Ris een transitierelatie op U <> R cUXxU. 


Meestal is het gewenst dat voor elke toestand v e U de transitie van v naar zichzelf ook 
geoorloofd is. Zo'n "pas op de plaats” kan bijvoorbeeld optreden bij een poging tot 
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verwijdering van een tupel dat niet in v blijkt voor te komen. Kortom, meestal willen we dat 
zo’n transitierelatie R reflexief op U is, dat wil zeggen Vve U :(v;wje R. 


VOORBEELD 5.1: 
Stel dat er in de organisatie met het hieronder beschreven DB-universum VBU, afkom- 
stig uit Voorbeeld 1.3, de volgende eisen moeten gelden: 


(DCI) Er mogen geen bestaande afdelingsnummers vervallen (hoewel bijvoorbeeld 
de naam van een afdeling wel mag veranderen). 


(DC2) Een medewerker moet altijd aan dezelfde afdeling verbonden blijven. 


(DC3) Salarissen van medewerkers mogen niet afnemen. 


Om de constraints (DC2) en (DC3) te kunnen formaliseren, zullen we aannemen dat 
een medewerker "in de loop der tijd" hetzelfde identiteitsnummer behoudt. We kunnen 
nu deze constraints formeel weergeven door middel van de hieronder gedefinieerde 
transitierelatie VBR op VBU. (Volledigheidshalve herhalen we ook nog even de 
definitie van het DB-universum VBU.) 


FM={(NR 5; WN), 
(NAAM ; Chs (40)), 
(SAL ; AN), 
(GESL ;{ M’,:“V’)), 
(AFDNR; [1 … 99])}; 


FA={(ANR ; WN), 
(NAAM ; Chs (45)), 
(MANNR ; IN}; 
WM = {T | T c II(FM) en {NR} is wi. in T}; 


WA = {T | T cTI(FA) en {ANR} is ui. in Ten {NAAM} is u.i. in T}; 


HF = ((MEDEW ; WM), 
(AFD ; WA)}; 


VBU = {v | v e II(HF) en 
{(AFDNR; ANR)} verbindt VMEDEW) met v(AFD) en 
{(MANNR; NR)} verbindt v(AFD) met vVMEDEW)}; 
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VBR = {(v; v) | (v; v) e VBU x VBU en 


v(AFD) MANR} c v/(AFD) MANR) en (DCI) 

Vt e v(MEDEW): Vt’ e v’(MEDEW): 

[als (NR) = t’(NR) dan (t(AFDNR) = t’(AFDNR) (DC2) 
en (SAL) S t’(SAL))]} (DC3) 


O Voorbeeld 5.1. 


De eisen waaraan de toestanden in een organisatie moeten voldoen, noemen we statische 
constraints en de eisen waaraan de transities moeten voldoen, noemen we wel dynamische 
constraints. 


We willen er op wijzen dat het soms onwenselijk is om dynamische constraints als 
"keiharde" constraints op te vatten. Het kan namelijk voorkomen dat een bepaalde transitie 
achteraf onjuist of onbedoeld bleek te zijn maar helaas wegens de dynamische constraints 
niet meer ongedaan kan worden gemaakt. Als bijvoorbeeld reeds aanwezige afdelingsnum- 
mers (of ordernummers) niet meer mogen vervallen, dan kan het abusievelijk toevoegen van 
een afdeling (of een order) niet meer ongedaan worden gemaakt. We zeggen in dat geval wel 
dat de transitie irreversibel is: 


DEFINITIE 5.2: 

Als (x ; y) een geordend paar is en R is een verzameling geordende paren, dan: 
(a) (x;y) is reversibel in R <> (y; x) e Tcl(R); 

(b) (x;y) isirreversibelinR <> (y:x)¢ Tcl(R). 


Als R uitsluitend reversibele elementen bevat, dan noemen we R zelf ook reversibel: 


DEFINITIE 5.3: 
Als R een verzameling geordende paren is, dan: 
R is reversibel <> Vp € R: pis reversibel in R. 


Bij niet-reversibele transitierelaties wordt een dynamische constraint vaak niet gebruikt als 
"keiharde" constraint maar meer als waarschuwingscriterium ("Wilt u dit écht?") of als een 
voorwaarde waaronder er speciale toestemming nodig is om de wijziging toch door te 
voeren. Dit betekent dus dat deze dynamische constraints dan niet als echte transitie- 
invarianten gebruikt kunnen worden. 
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In het volgende voorbeeld bespreken we enige algemene vormen van dynamische 
constraints. Elke algemene vorm wordt tevens toegelicht aan de hand van VBU of VBR uit 
Voorbeeld 5.1. 


VOORBEELD 5.2: 
We gaan uit van een DB-skelet g, een DB-universum U over g, E e dom(g), S c 2(E), 
Bc gE), C c g(E)ena e g(E), waarbij de a-waarden voor E getallen zijn. We zul- 
len de constraint-vormen uitdrukken in termen van een willekeurige transitie (v ; v^) 
binnen U. 


(V1) De E-tabel is cumulatief, dat wil zeggen alle E-gegevens blijven ongewijzigd 
aanwezig. Kortom, er mogen geen E-tupels vervallen: 


v(E) c v(E). 


Het is interessant op te merken dat deze dynamische constraint is op te vatten als 
een verbindingseis "door de tijd heen": 


id (2(E)) verbindt v (E) met v’(E). 


Voor E= AFD in VBU zou deze eis nogal wat inhouden, namelijk dat een 
afdeling(snummer) niet mag vervallen, dat de bijbehorende afdelingsnaam niet 
mag veranderen en dat ook de manager van die afdeling niet mag worden ver- 
vangen. In feite is dus het toevoegen van geheel nieuwe afdelingen de enig toe- 
gestane verandering op de afdelingentabel. 

Wanneer de E-tabel voor bijvoorbeeld logging-activiteiten bedoeld is, dan kan 
deze zware eis van cumulativiteit wel realistisch zijn. 


(V2) Er mag geen enkele combinatie van waarden van primaire attributen - dat wil 
zeggen attributen die element van een minimale sleutel zijn (zie de definities 2.13 
en 2.19) - in de E-tabel vervallen: 
id(Prim (E , U)) verbindt v(E) met v’(E). 

Voor E = AFD in VBU betekent dit: 


(ANR, NAAM} verbindt v(AFD) met v’(AFD). 


Met andere woorden, een afdelingsnummer mag niet vervallen en de 
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bijbehorende afdelingsnaam mag niet veranderen; de manager mag echter wel 
worden vervangen (en ook mogen er nieuwe afdelingen bijkomen). 
Merk op dat de eis (V1) de eis (V2) impliceert. 


(V3) De E-tabel is cumulatief met betrekking tot S, dat wil zeggen er mogen geen S- 
waarden vervallen: 


v(E) | S cvE) JS. 
We kunnen dit ook weer formuleren als een verbindingseis: 
id(S) verbindt v(E) met v’(E). 


Een voorbeeld van deze vorm van dynamische constraint is de eis (DCI) uit 
Voorbeeld 5.1. 


Als S uitsluitend primaire attributen bevat, bijvoorbeeld als S een minimale sleu- 
tel van E in U is, dan geldt S c Prim(E , U); in dat geval impliceert de eis (V2) 
de eis (V3). 


(V4) Bij elke B-waarde die aanwezig blijft in de E-tabel moeten de bijbehorende C- 
waarden constant blijven: 


Vte v(E): Vrt’ e v(E): alst) B =t} Bdant} C =r} C. 


De eis (DC2) uit Voorbeeld 5.1 is een speciaal geval van deze vorm. (Neem U = 
VBU, E = MEDEW, B = {NR} en C = {AFDNR}.) 


Als B een sleutel van E in U is en S =B U C in (V3), dan impliceert die eis (V3) 
de eis (V4). 


(V5) De a-waarde van elk E-tupel in de nieuwe toestand moet ten minste even groot 
zijn als de a-waarde van elk E-tupel in de oude toestand met dezelfde S-waarde: 


Yt e v(E): Vt’ v(E): als t} S =r} S dan t(a)s t’(a). 


Bij deze vorm zal S meestal een sleutel van E in U zijn, zoals bijvoorbeeld het 
geval is bij de eis (DC3) uit Voorbeeld 5.1. 
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Als B =S en C = {a} in (V4), dan impliceert die eis (V4) de eis (V5). 


(V6) Het aantal E-tupels mag niet afnemen: 
lv(E)|< | v(E) I. 


Voor E = AFD in VBU zou dit betekenen dat afdelingen niet zonder meer mogen 
vervallen maar kennelijk wel mogen worden vervangen door andere afdelingen. 


Als S in (V3) een sleutel van E in U is, dan impliceert de eis (V3) de eis (V6). 


O Voorbeeld 5.2. 


In de voorbeelden 5.1 en 5.2 zagen we dat er soms voor één van de minimale sleutels van E 
in U een speciale rol is weggelegd. De achterliggende gedachte is dat de waarden voor die 
speciale sleutel in de loop der tijd één-één-duidig blijven corresponderen met de gerepresen- 
teerde "real-world" objecten zelf. We noemen zo’n speciale minimale sleutel wel een pri- 
mary key. De andere minimale sleutels noemen we in dit verband wel alternate keys. Hoewel 
het onderscheid tussen primary keys en alternate keys in de literatuur meestal op andere (en 
vaak niet altijd duidelijke) gronden wordt gemaakt, lijkt ons de zojuist genoemde reden nog 
het meest zinvolle argument voor zo’n onderscheid. Een nadere discussie over dit onderwerp 
kan de lezer onder meer vinden in Hoofdstuk 3 van [Da 86b]. 


In Voorbeeld 5.2 hebben we tevens gezien dat het verbindingsbegrip niet alleen van dienst is 
voor de formulering van statische constraints maar ook voor die van dynamische constraints. 
In die gevallen is de verbindende attributentransformatie uiteraard een identieke functie. 


Voor de klasse van dynamische constraints die we in (V4) van Voorbeeld 5.2 tegenkwamen, 
willen we een aparte naamgeving en notatie invoeren. We zullen daarom in onderstaand 


geval C transitie-afhankelijk van B bij (T;T’) noemen, naar analogie van momentane 
afhankelijkheid. 


DEFINITIE 5.4: 
Als A, B en C verzamelingen zijn en T en T’ zijn tabellen over A, dan: 


B 3 Cbij(T;T’) <>Vte T: Vt e Talst) B=t’) Bdant)} C=r} C. 


De eis (V4) van Voorbeeld 5.2 kunnen we nu dus schrijven als: B > C bij (v(E); v’(E)). 
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Het volgende lemma is het analogon van Lemma 2.7 en geeft enige elementaire eigenschap- 
pen van transitie-afhankelijkheid weer. 


LEMMA 5.1: 
Als A een verzameling is en T en T” zijn tabellen over A en B c A en C c Aen D CA, dan: 


(a) als C cB, dan B 3C bij (T;T’); 
(b) als B SC bij (T; T’) en C 5 D bij (T; T’), dan B 5 D bij (T ; T^; 
(c) B C bij (T; T’) desda Vc e C : B 5 {c} bij (T; T^). 


Lemma 5.2 relateert transitie-afhankelijkheid aan momentane afhankelijkheid (en in (c) aan 
zichzelf). 


LEMMA 5.2: 

Als A een verzameling is en T en 7’ zijn tabellen over A en B c A en C CA, dan: 
(a) B-oCinT <> B->Cbij(T;T); 

b) BoCinTUT’ <> B5SCbij(T;T)jenB > CinTenB >CinT’: 
(c) BSCbij(T;T) <> B 5C bij (7';T). 


De bewijzen van deze lemma’s worden als opgaven aan de lezer overgelaten. Ter illustratie 
van onderdeel (b) van Lemma 5.2 merken we op dat in Voorbeeld 5.1 de dynamische con- 
straint DC2 samen met de uniciteitseis in de definitie van WM equivalent is met de dyna- 
mische constraint dat {NR} — {AFDNR} in v(MEDEW) U v'(MEDEW). 


We willen het begrip transitie-afhankelijkheid vooral ook definiëren op het niveau van tran- 
sitierelaties: We zullen in onderstaand geval C constant afhankelijk van B in E bij R noemen. 


DEFINITIE 5.5: 

Als g een verzamelingsfunctie is en U is een DB-universum over gen E e dom(g)enBenC 
zijn verzamelingen en R c U x U, dan: 

B SCinEbijR <>Wv;v’)e R:B 5 C bij VE); vE). 


Een eenvoudige maar belangrijke constatering is dat bij reflexieve transitierelaties per- 
manente afhankelijkheid uit constante afhankelijkheid volgt: 
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STELLING 5.1: 

Als g een verzamelingsfunctie is en U is een DB-universum over g en E e dom(g) en 
_Beg(B)enC cg(E)enR cU xU, dan: 

als B 5 C in E bij R en R is reflexief op U dan B 5 C in E van U. 


Bewijs: 
Te bewijzen dat Vve U : B > Cinv(E); 


B 5 CinE bij R 


<> Vv; v’) e R : B >C bij (v(E); v'(E)) (volgens Definitie 5.5) 

> Vve U:B C bij (v(E); v(E)) (omdat R reflexief op U is) 
<> Vve U:B > Cinv(E) (volgens Lemma 5.2 (a)) 
oO 
OPGAVEN 


5.1. Is VBR reflexief op VBU in Voorbeeld 5.1? 


5.2. In Voorbeeld 5.1 denken we aan FM het geordend paar (ST; { ‘0’, ‘H’, ‘S’, ‘W? }) 
toegevoegd; hierbij staat ST voor status, ‘O’ ongehuwd, ‘H’ voor gehuwd, ‘S’ voor 
gescheiden en ‘W’ voor weduwe of weduwnaar. Geef formeel weer welke eisen er aan 
de definitie van VBR zouden moeten worden toegevoegd. 


5.3. Geef de volgende dynamische constraints voor een transitie (v ; v’) binnen VBU uit 
Voorbeeld 5.1 formeel weer. 


(a) Het aantal medewerkers van een afdeling mag niet met meer dan vijf personen in 
één keer stijgen. 

(b) Het aantal medewerkers van een bestaande afdeling mag niet met meer dan vijf 
personen in één keer stijgen. 

(c) Het aantal medewerkers van een manager mag niet met meer dan vijf personen in 
één keer stijgen. 


(d) Het aantal medewerkers van een "prille" manager mag niet meer dan vijf per- 
sonen bedragen. 
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5.4. 


5.9. 


5.6. 


bi 


5.8. 


(a) Leg uit waarom VBR uit Voorbeeld 5.1 niet reversibel is. 
(b) Geef (desondanks) een reversibel element (v ; v^) van VBR zodanig dat v +v’. 


(c) Leidt het verhogen van een salaris van een medewerker tot een irreversibele tran- 
sitie in VBR? 


In Voorbeeld 5.2 eindigen (V2) tot en met (V6) elk met een implicatie. Bewijs die vijf 
implicaties. 


Geef voor elk van de constraint-vormen (V1) tot en met (V6) in Voorbeeld 5.2 aan 
onder welke (eventuele) extra voorwaarden een transitie (v ; v) met v e VBU aan die 
constraint-vorm voldoet. 


Vervang in de verwoording van de eisen in (V1), (V2) en (V3) van Voorbeeld 5.2 het 
woord "vervallen" door het woord "bijkomen" en geef deze drie nieuwe eisen weer met 
behulp van het verbindingsbegrip. 


Is de eis (V2) van Voorbeeld 5.2 equivalent met de uitspraak dat er geen enkele waarde 
van een minimale sleutel mag vervallen? 
Geef een bewijs of een tegenvoorbeeld voor elk van de twee gevraagde implicaties. 


5.9. Bewijs Lemma 5.1. 


5.10. Formuleer en bewijs het analogon van Lemma 2.8. 


5.11. Als A een verzameling is en T en T’ zijn tabellen over Aen B CA en C CA, dan: 


(a) BC bij (@; T^); 

b BOO bij (T ; T°); 

(c) ØC bij (T ; T^) desda T =@ of T’ =@of IT DAREN CISL 
Bewijs dit analogon van Lemma 2.9. 


5.12. Bewijs Lemma 5.2. Laat eveneens zien dat uit B 5 C bij (T ; T’) nog niet volgt dat 


B>CinTuT. 
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5.13. Als A een verzameling is en T en T’ zijn tabellen over Aen B c A en C CA, dan: 
(a) alsB 5C bij (T; T^, dan B > C in (T pa T’ |Ì B) U (T' pa T | B); 
(b) als B u.i. in T is en B is u.i. in T’, dan: 


(B->C bij (T;T)enT |} BCT’ [ B)<>T BUC)cT |BVUC). 
Bewijs dit. 


5.14. We noemen een verzameling R van geordende paren symmetrisch desda 
Wx; yje R: ix)ER. 
Bewijs nu het volgende. 
Als R een verzameling geordende paren is, dan: 


(a) Als R symmetrisch is, dan is R reversibel. 


(b) De volgende drie beweringen zijn equivalent: 
(b1) R is reversibel; 
(b2) Tcl(R) is reversibel; 
(b3) Tcl(R) is symmetrisch. 


(c) Als R reversibel is, dan Vp e Tcl(R): p is reversibel in R. 


5.2 EEN NIET-TRIVIAAL VOORBEELD VAN EEN TRANSITIERELATIE 


Om een indruk te geven van de mogelijke (subtiele) verschijningsvormen van dynamische 
constraints in de context van een op zich reeds complex database-universum, zullen we in 
deze paragraaf een niet-triviale transitierelatie op het database-universum UZKH uit 
Hoofdstuk 4 definiëren. 


We beginnen met een informele beschrijving van de dynamische constraints, vervolgen met 
een "semi-formele" tussenvorm van sommige van de meer subtiele constraints (als analyse- 
hulpmiddel) en eindigen met de formele definitie van de transitierelatie RZKH op UZKH. 
Evenals in Hoofdstuk 4 geldt ook hier (en meer in het algemeen) dat een informele 
beschrijving meestal niet voldoende duidelijk is om daar de formele definitie eenduidig uit te 
kunnen afleiden. 
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We beginnen met een informele beschrijving van de dynamische constraints voor het 
medische gedeelte en de daarmee verbonden administratie, direct gevolgd door die voor de 
personele aangelegenheden. 


(C00) 


(C01) 
(C02) 
(C03) 


(C04) 


(C05) 


(C06) 


(C07) 
(C08) 
(C09) 


(C10) 
(C11) 
(C12) 


(C13) 


Een afdeling(snummer) mag niet vervallen; wel mag bijvoorbeeld de naam of de 
chef of de souschef van een afdeling veranderen. (Souschefs verwelken, chefs die 
vergaan, maar onze afdelingen blijven altijd bestaan.) 


Alle medicijnverstrekkingsgegevens moeten ongewijzigd aanwezig blijven. 
Ook alle patiëntbehandelingsgegevens moeten ongewijzigd aanwezig blijven. 


Na invoering moeten van elke opname de volgende gegevens ongewijzigd 
aanwezig blijven: patiëntnummer, opnamedatum, ruimtenummer, identiteitsnum- 
mer van de in eerste instantie verantwoordelijke specialist en de gegevens van de 
(toenmalige) huisarts van de patiënt. 


Van elke beëindigde opname moeten ook de andere opnamegegevens ongewijzigd 
aanwezig blijven, evenals de bijbehorende ontslaggegevens. 


Bijna alle overdrachtgegevens moeten ongewijzigd aanwezig blijven: alleen de 
opnamereden kan nog worden gewijzigd. 


Ook bijna alle overplaatsingsgegevens moeten ongewijzigd aanwezig blijven: 
alleen aan de verpleegkundige bevindingen kunnen nog opmerkingen worden toe- 
gevoegd. (Reeds aanwezige aantekeningen mogen namelijk niet meer worden 
gewijzigd of verwijderd.) Met het oog op de te geven formalisatie van deze eis 
wijzen we nog eens op de voorlaatste alinea vóór Definitie 0.21. 


Een medicijn(code) blijft altijd van dezelfde soort. 
Een behandeling blijft ook altijd van dezelfde soort. 


Van elke patiënt die in de administratie aanwezig blijft, mogen de volgende 
gegevens niet meer worden gewijzigd: geboorteplaats, geboortedatum, inschrijfda- 
tum, bloedgroep en rhesusfactor. 


Voor mannelijke patiënten moet ook de naam ongewijzigd blijven. 
Van een werknemer mag het salaris per halve dag per week niet afnemen. 


Van een werknemer kan het aantal ziektedagen niet afnemen, met uitzondering van 
de momenten waarop voor alle werknemers het aantal ziektedagen weer op nul 
wordt gezet. 


De vakbonden hebben kunnen afdwingen dat er niet mag worden bezuinigd op het 


aantal vrije dagen per jaar (op basis van een volledige betrekking) van een niet- 
medisch personeelslid dat verplicht verzekerd is. 
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(C14) 


(C15) 
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Bij een wijziging in de gegevens over het patiëntenaantal, de vorige 
patiëntentoename of de verwachte patiëntentoename van een huisarts moet de 
nieuwe "patiëntentoename vorig jaar" gelijk zijn aan het verschil tussen het nieuwe 
aantal patiënten en het oude aantal patiënten van die huisarts. (In tegenstelling tot 
de eveneens als jaarlijks bedoelde wijzigingen genoemd in C12, die voor alle 
werknemers tegelijk moeten gebeuren, moeten de in C14 bedoelde wijzigingen 
afzonderlijk per huisarts kunnen geschieden.) 


In verband met de continuiteit van een afdeling mag de leiding van een afdeling, 
dat wil zeggen chef plus souschef van die afdeling, niet in één keer worden ver- 
vangen door twee geheel nieuwe personen. (Wel mag bijvoorbeeld de chef 
verdwijnen en gelijktijdig de souschef de nieuwe chef van die afdeling worden.) 


Wat betreft de "life-cycle" van een ruimte in ons ziekenhuis gelden de volgende regels en 
nevenvoorwaarden. 


(C16) 


(C17) 


(C18) 


(C19) 


Alle "vervallen" ruimten in de nieuwe toestand moeten reeds in de oude toestand 
bekend zijn, maar dan niet met de status “gepland”. (Een ruimte mag namelijk niet 
“vanuit het niets” meteen vervallen en van een geplande ruimte die er uiteindelijk 
niet komt worden de gegevens gewoon verwijderd.) 


Elk ruimtenummer met de status "aanwezig" moet blijven bestaan, moet daarbij 
dezelfde oppervlakte houden en kan niet meer de status "gepland" krijgen. 


Voor aanwezige behandelruimten en verpleegruimten moet bovendien de soort 
ongewijzigd blijven. (Recepties, magazijnen en "diverse" ruimten mogen wél van 
soort veranderen; ze kunnen in principe zelfs verpleegruimten of behandelruimten 
worden. Echter, verpleegruimten en behandelruimten die voor andere doeleinden 
gebruikt gaan worden, zullen administratief als "vervallen" worden beschouwd en 
onder een ander ruimtenummer verder gaan in ons ziekenhuis. We merken hierbij 
overigens op dat dergelijke administratieve constructies in de praktijk niet onge- 
bruikelijk zijn.) 

De gegevens van alle "vervallen" ruimten moeten in de nieuwe toestand 
ongewijzigd blijven bestaan. 


De volgens C16 tot en met C19 voor een ruimtenummer enig toegestane statusovergangen 
hebben we schematisch weergegeven in het volgende diagram (waarbij "~" de situatie 
aangeeft dat het ruimtenummer niet voorkomt in de ruimte-tabel): 
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ws LZ EZ LZ 
et} ar 


De mogelijke statusovergangen voor een ruimte(nummer) 


De wel en niet toegestane statusovergangen kunnen we ook weergeven met behulp van een 
matrix: 


GEPL AANW VERV 


De mogelijke statusovergangen in matrixvorm 


De reden voor een niet toegestane statusovergang en de eventuele nevenvoorwaarden voor 
een wel toegestane statusovergang zijn hieronder aan de hand van de betreffende C-nummers 
weergegeven. De ingetekende rechthoeken geven hierbij aan op welke gevallen de 
genoemde constraints van toepassing zijn. (Hierbij is te v(RU), t'e v’(RU) en (RNR) 
= t’(RNR).) 


GEPL AANW VERV 


C17 en C18 


eae 


Ad C17: (OPVL) =t(OPVL) | 
Ad C18: als (SRTR) € { ‘BHR’, ‘VPR’} dan (SRTR) = t’(SRTR) 
Ad C19: t=?’ 


Dergelijke schematische weergaven kunnen wel eens nuttig zijn tijdens het inventariseren 
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van dynamische constraints, als hulpmiddel om tot de uiteindelijke formulering te kunnen 


komen. 


Wat betreft het (carrière)verloop van specialisten houdt ons ziekenhuis de volgende regels en 
nevenvoorwaarden in acht. 


(C20) 


(C21) 


(C22) 


(C23) 


Elke specialist die in de nieuwe toestand voorkomt als zijnde niet in dienst, komt 
reeds in de oude toestand voor met dezelfde locum tenens, hetzelfde soort dienst- 
verband, dezelfde specialismen, hetzelfde honorarium per uur, hetzelfde afde- 
lingsnummer en hetzelfde interne telefoonnummer. (Tijdens het uit dienst gaan en 
het uit dienst zijn van een specialist mogen deze gegevens namelijk niet meer wor- 
den veranderd.) 


Een specialist blijft altijd in de administratie aanwezig, met ten minste dezelfde 
specialismen als voorheen. (Deze eis wordt gesteld omdat er in de gegevens over 
het medisch handelen, met name bij opnamen, overdrachten, patiëntbehandelingen 
en medicijnverstrekkingen, veelvuldig wordt verwezen naar de specialisten die er 
destijds bij waren betrokken.) 


Omdat een specialist altijd in dienst is op basis van een contract met een afdeling, 
zal een specialist die in dienst is en blijft, in de nieuwe toestand altijd hetzelfde 
afdelingsnummer, soort dienstverband, aantal uren in de week en aantal toe- 
gezegde bedden behouden; verder mag het honorarium per uur niet dalen. 


Bij een transitie zullen de identiteitsnummers voor nieuwe specialisten getallen 
zijn vanaf 100 plus het aantal reeds geadministreerde specialisten; deze nieuwe 
identiteitsnummers moeten echter wel kleiner zijn dan 100 plus het nieuwe aantal 
geadministreerde specialisten. 


De dynamische constraints voor specialisten, C20 tot en met C23, zullen we weergeven op 
een soortgelijke manier als die voor ruimten in ons ziekenhuis. We beginnen met een "transi- 
tiediagram" op grond van het wel of niet in dienst zijn. In dit diagram representeert geval (1) 
het in dienst treden, (2) het in dienst blijven, (3) het uit dienst treden, (4) het uit dienst 
blijven, en (5) het opnieuw in dienst treden. 
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De "life-cycle" van een specialist 


In de nu volgende matrixrepresentatie houden we dezelfde nummering aan als in het voor- 
gaande diagram. Omdat de gegevens van een specialist zijn verdeeld over twee tabellen, de 
SP-tabel en de MW-tabel, nemen we nu te v(SP) >< MW), t e v’(SP) pq v’(MW) en 
t(IDNR) = t’(IDNR). 


Ad C20: t = t’ op (LOC, SDV, SPEC, HONU, ANR, TELI}; zie Definitie 0.15. 
Ad C21: (SPEC) c t’(SPEC). 
Ad (2), C22: t = t’ op (SDV, AUW, ABD, ANR} en (HONU) S t’(HONU). 


Eis C23, die uitsluitend op geval (1) slaat, is iets anders van aard en kan met behulp van 
intervallen als volgt worden geformuleerd: 


{t (IDNR) | te v’(SP)} — {t(IDNR) | te v(SP)} c [100 + | v(SP) I .. 100 + | v’(SP) 1) 


We besluiten deze paragraaf nu met de formele definitie van de door de voorgaande dyna- 
mische constraints bepaalde transitierelatie RZKH op UZKH. 
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RZKH = 
{(v; v^) | (v; v) e UZKH x UZKH en 
Y(AFD) | {ANR} c v’(AFD) | {ANR} en 
v(MVS) c v’(MVS) en 
v(PB) < v(PB) en 
id({PNR, OPND, RNR, IDNR, NAWH}) verbindt v(OPN) met v’(OPN) en 
(OPN) >< WONT) c v’(OPN) >< v’(ONT) en 
v(OSP)#{OPNR} c v’(OSP)#{OPNR} en 
[Vt e (OVR): dt’ € v'(OVR): (tt {BEV} =t’t{BEV} en (BEV) c t’(BEV))] en 
{MCD} 5 {MSRT} bij (v(MED); v’(MED)) en 
{BCD} 5 {BSRT} bij (BEH); v’(BEH)) en 
{PNR} > (GPL, GBD, INSD, BLGR, RHF} bij (v(PAT); v’(PAT)) en 
[Vt e v(PAT): Vt’ e v'(PAT): als (PNR) = t’(PNR) en (GESL) = ‘M’ 

dan (NAW) (NM) = t’(NAW) (NM)] en 
[Vt e (WN): Vt’ € v'(WN): als (IDNR) = t’(IDNR) 

dan £(SAL/t(AHD) S t’(SAL)/t’(AHD)] en 
[((Vt e v(WN): Yr’ e v’(WN): als (IDNR) = t’(IDNR) dan t(AZD) S t’(AZD)) 

of (Vt’ e v'(WN): t’(AZD) =0)] en 
[Vt e v(NMP) pq v(VV): Vt’ e v’(NMP): als (IDNR) = t’(IDNR) 
dan t(AVD)< t’(AVD)] en 
[Vt e (HA): Vt’ e v'(HA): als (NRHA) = £(NRHA) en 
t lijkt niet op t’ t.a.v. (PAT, TOEN, VWIN} 

dan t’(TOEN) = t’(PAT) — t(PAT)] en 

[Vt e v(AFD): Vt’ e v'(AFD): als (ANR) = t’(ANR) 


dan {t(CHNR), £SCNR)} A {t’(CHNR), t’(SCNR)} # 2] en 


id({RNR}) verbindt 
(t’ e v'(RU) | (STAT) = ‘VERV’ } met {t e v(RU) | (STAT) # ‘GEPL’ } en 
id({RNR, OPVL}) verbindt 
(te WRU) | (STAT) = ‘AANW’ } met {t’ e v'(RU) | t’(STAT) + ‘GEPL’ } en 
id({RNR, SRTR}) verbindt 
{t e RU) | (STAT) = ‘AANW’ en SRTR) e { ‘BHR’, ‘VPR’ }} met v’(RU) en 
(te v(RU) | STAT) = ‘VERV’ } c v’(RU) en 
id({IDNR, LOC, SDV, SPEC, HONU, ANR, TELI}) verbindt 
{t e v(SP) pq v’(MW) | t’(IND) = ‘NEE’ } met v(SP) pq v(MW) en 
[Vt e (SP) pq MW): Jt’ e v’(SP) pa v'(MW): 
(t(IDNR) = t’(IDNR) en (SPEC) c t’(SPEC) en 
als (IND) = t’(IND) = ‘JA’ 
dan (f(HONU) S t’(HONU) en t lijkt op t’ t.a.v. (SDV, AUW, ABD, ANR}))] en 


(£(IDNR) | t’ € v(SP)} — (IDNR) | t e vSP)} < [100 + I v(SP) | … 100 + | v'(SP) 1) }. 
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OPGAVEN 


5.55: 


5.16. 


5.17. 


5.18. 


5.19. 


(a) Is RZKH reflexief op UZKH? 
(b) Is RZKH reversibel? 
Licht uw antwoorden toe. 


Blijven bij RZKH van specialisten die bij een transitie uit dienst zijn én blijven, alle 
SP-gegevens ongewijzigd? Zo ja, geef dan aan uit welke constraints dit volgt; zo nee, 
noem dan alle SP-attributen waarvan de waarde in zo’n geval wel kan wijzigen. 


Ga voor elk van de volgende beweringen de geldigheid in UZKH c.q. RZKH na. Noem 
voor elke geldige bewering de constraint(s) waaruit die bewering volgt; geef voor elke 
andere bewering aan of het een statische dan wel dynamische constraint is en geef dan 
tevens de formele weergave. 

(a) Een specialist mag nooit van afdeling veranderen. 


(b) Zolang een werknemer verplicht verzekerd is, mag die persoon niet van soort 
afdeling veranderen. 

(c) Patiënten die ooit een opname, behandeling of medicijnverstrekking hebben 
gehad, verdwijnen niet meer uit de administratie. 


(d) Behandelingen die ooit uitgevoerd zijn en medicijnen die ooit verstrekt zijn, ver- 
vallen niet. 


(e) Het aantal in dienst zijnde medewerkers stijgt niet. 
(f) Alleen van de meest recente overdracht van een patiënt kan de opnamereden 


alsnog worden aangepast. 


(g) Alleen van de meest recente overdracht van een nog opgenomen patiënt kan de 
opnamereden alsnog worden aangepast. 


Bedenk zelf nog enige dynamische constraints over UZKH en geef ze zowel in woor- 
den als formeel weer. 


Bewijs dat {t’(IDNR) | t’ e v’(SP)} = [100 … 100 + | v’(SP) |) voor elke v’ € UZKH 
die volgens RZKH bereikbaar is vanuit de lege toestand, dus voor elke v’ €e UZKH 
waarvoor (AE e dom(GZKH): Ø ; v’) e Tcl(RZKH). 

(Hint: gebruik volledige inductie.) 


6 RAADPLEGING 


Onder raadpleging van een database verstaan we, informeel verwoord, het opvragen van 
gegevens van een willekeurige (DB-)toestand van het (DB-)universum in kwestie. Meer 
specifiek kunnen we een vraag (of opdracht of "query") opvatten als een functie die aan elke 
toestand van het betreffende universum een “antwoord” toevoegt, bijvoorbeeld een tabel, een 
getal of een ja/nee-antwoord. Raadpleging wordt ook wel vaak "retrieval" genoemd. 


We maken onderscheid tussen het formuleren, het stellen en het uitrekenen van een vraag. 


° Het formuleren van een vraag komt neer op het specificeren van een functie over het 
universum in kwestie, een functie die aan elke toestand het gevraagde toevoegt. 


° Het stellen van een vraag q aan een database in toestand v komt neer op het toepassen 


van de functie q op het argument v. We noemen q(v) wel het antwoord op vraag q in 
toestand v. 


° Het uitrekenen van het antwoord op vraag q in toestand v komt neer op het bepalen van 
de "meest eenvoudige” representatievorm van het antwoord q (v). 


In een geautomatiseerde omgeving is het formuleren van vragen typisch een taak voor de 
ontwerpers, de applicatiebouwers en de meer ervaren gebruikers van het systeem, het stellen 
van vragen vooral een taak van de eindgebruikers, en het uitrekenen van vragen typisch een 
taak voor het (database-management)systeem in kwestie. 


In dit hoofdstuk zullen we met name ingaan op het formuleren van vragen. 
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6.1 QUERIES 


In de inleiding hebben we reeds informeel verwoord wat we onder een vraag verstaan. We 
geven nu een formele definitie van dit begrip. In die definitie kan het universum een wil- 
lekeurige verzameling zijn. Voor dit formele begrip zullen we in het vervolg de Engelse term 
query gebruiken. 


DEFINITIE 6.1: 
Als U een verzameling is, dan: 
q is een query over U S q is een functie over U. 


VOORBEELD 6.1: 
We geven twee voorbeelden van queries, één over een tabellenverzameling en één over 
een DB-universum. 


1. De opdracht "Geef het aantal personen die niet in hun geboorteplaats wonen" 
over de tabellenverzameling WP uit Voorbeeld 2.8 kunnen we formeel als volgt 
weergeven: 


AT e WP: I (te T | t(WPL) # t(GPL))} | 


Het antwoord op deze vraag in de toestand weergegeven in Figuur 2.7 is ken- 
nelijk 3. 
2. De analoge opdracht "Geef het aantal patiënten die niet in hun geboorteplaats 


wonen” over het DB-universum UZKH uit Hoofdstuk 4 kunnen we formeel als 
volgt weergeven: 


Ave UZKH: | (te v(PAT) | (NAW) (WPL) + t(GPL)} | 


O Voorbeeld 6.1. 


Met behulp van de tot nu toe ingevoerde begrippen en notaties zijn we in feite in staat om de 
meest uiteenlopende queries te specificeren. Om een indruk te geven zullen we in de vol- 
gende voorbeelden telkens enige illustratieve klassen van vragen behandelen (K1, K2, 
etcetera). Daarbij geven we onder (A) de algemene vorm, onder (B) een specifiek voorbeeld 
(aan de hand van het semantisch rijke DB-universum UZKH uit Hoofdstuk 4), en eventueel 
onder (C) nog enige opmerkingen. (Overigens doet de informele verwoording bij (B) niet 
altijd meteen vermoeden dat het in feite een vraag van de onder (A) beschreven vorm 
betreft.) Enkele vragen onder (B) en in de opgaven zijn varianten op de vragen in [Re 82], 
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Hoofstuk 8. In de praktijk kan het nuttig zijn om voor een vraag verschillende formele weer- 
gaven achter de hand te hebben, bijvoorbeeld omdat een bepaalde op zichzelf correcte 
oplossing niet zonder meer uitdrukbaar is in de query-taal van het DBMS in kwestie of 
omdat een andere verwoording opeens tot een aanzienlijk kortere responsetijd kan leiden. 
We zullen daarom onder (A) soms meer dan één oplossing geven. Onder (B) gebruiken we 
telkens één van deze genummerde varianten voor het specifieke UZKH-voorbeeld. 


In de onder (A) genoemde algemene vormen van de voorbeelden gaan we uit van een DB- 
universum U over een DB-skelet g, tabelindexen E en E’ met {a,b,c,d,e} c g(E), A c g(E) 


en d'e g(E’), BC g(E) CO g(E’), een DB-functie H over U m.b.t. (E; E’) en een DB- 
functie G over U m.b.t. (E’; E). 


Elk van de vragen in Voorbeeld 6.2 heeft betrekking op slechts één tabel. 


VOORBEELD 6.2: 
K1: (A) Geef alle gegevens uit de E-tabel. 
(1) Ave U:v(E) 
(B) Geef de gegevens van alle plaatsen in de regio. 
(1) Ave UZKH: v(PLR) 
(C) Het antwoord bestaat dus uit een tabel. 


K2: (A) Geef de A-waarden van alle E-tupels. 
(1) Ave U:v(E) |A 
(2) Ave U:{tl A Ite v(E)) 

(B) Geef code, naam en voorraad van elk medicijn. 

(1) Ave UZKH : v(MED) | (MCD, MNM, VRD) 

(C) Als de attributenverzameling A in (A) geen sleutel van E in U is, dan kan in 
sommige toestanden v het aantal tupels in het antwoord kleiner zijn dan het 
aantal tupels in de tabel v(E) zelf. Bijvoorbeeld, bij de vraag "Geef elke 
medicijnsoort" is A gelijk aan {MSRT} en {MSRT} is geen sleutel van 
MED in UZKH. In een toestand v waarin er verschillende medicijntupels 


met dezelfde soort voorkomen zal het antwoord dus uit een kleiner aantal 
tupels bestaan dan v(MED) zelf. 
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K3: (A) 


(B) 


(C) 


K4: (A) 


(B) 


(C) 
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Geef de A-waarden van elk E-tupel waarvan de a-waarde x of de b-waarde 
ongelijk aan y is. 
(1) Ave U: {te v(E) | t(a)=xoft(b)#y} |A 
(2) Ave U:{thAlte v(E)en (t(a) =x of t(b) #y)} 
(3) Ave U: {t/ Alte v(E) en (als t(b) = y dan t(a) =x)} 
(4) Ave U:({te v(E) | t(a)=x} U (te v(E) | t(b) #y}) PA 
(5) Ave U:({te v(E) | t(a)=x} | A)U ((te v(E) | tb) #y} |A) 
(6) Ave U: {t}A Ite v(E)ent(a)=x} U 
{tt A lte v(E)ent(b)#y} 


Geef patiëntnummer, bloedgroep en rhesusfactor van alle vrouwelijke 
patiënten en van alle patiënten met kinderen. 


(6) Ave UZKH: 
(t| (PNR, BLGR, RHF} | t e v(PAT) en (GESL) = ‘V’} U 
{t| (PNR, BLGR, RHF} | t e (PAT) en (KNDG) # Ø} 


De volgende oplossing, waarin t een functie over A is, is alleen correct als 
{a,b} CA. 


(7) Ave U: {te v(E) |A 1 t(a) =xof t(b) #y} 


Zoals aangegeven hebben we in (B) een oplossing conform variant (6) 
onder (A) gegeven. 


Geef het aantal E-tupels waarvan de a-waarde niet als b-waarde in de E- 
tabel voorkomt. 


(1) Ave U:1 {te v(E) | tae (f(b) | te v(E)}} | 

(2) Ave U:| {te v(E) 1 Yr e v(E): t’(b) #t(a)} | 

(3) Ave U: | {te v(E)10=1 (te v(E) | t’(b) =t(a)} 1} | 

Geef het aantal specialisten die geen locum tenens zijn. 

(2) Ave UZKH: | (te v(SP) | Vt’ e v(SP): t’(LOC) + t(IDNR)} | 


Als {a} een sleutel van E in U is (zoals bijvoorbeeld in (B) het geval is), 
dan zijn ook de volgende varianten correct: 


(4) AveU:l(t(a)lte v(E)ent(a)¢ (t(b) | te v(E)}} | 
(5) Ave U: I (t(a)l te v(E)}-— (f(b) | t’ e v(E)) | 
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KS: 


K6: 


K7: 


(A) 


(B) 


(C) 


(A) 


(B) 


(C) 


(A) 


(B) 


(C) 


RAADPLEGING 


Geef de som van het produkt van de a-waarde en de b-waarde van alle E- 
tupels waarvan de c-waarde x , y of z is. 


(1) Ave U: (te v)ent(c)e {x,y,z} : t(a)* t(b)) 
Geef de totale verkoopwaarde van alle medicijnen waarvan de soort ‘K’, 
‘N’ of ‘O’ is. 
(1) Ave UZKH: 

(Xt e v(MED) en t(MSRT)e { ‘K’, ‘N’, ‘O’ } : (VRD) * t(VKPR)) 
Evenals bij de vorige vorm komt hier dus altijd één enkel getal uit. 


Geef met ‘JA’ of ‘NEE’ aan of er meer dan 1000 E-tupels zijn. 
(1) {ws TA’) Ive Uen l v(E) | > 1000} U 
{(v; NEE’) | ve Uen | v(E) |< 1000} 
(2) (ve Uen I| v(E) | > 1000: JA’) U 
(Ave Uen | v(E) |< 1000: NEE’) 
(3) (ve U: ‘NEE’)6(Ave Uen | v(E) | > 1000: JA’) 
(4) (veU: ‘JA’) 8(Ave Uen | v(E) |< 1000: NEE’) 
Geef met ‘JA’ of ‘NEE’ aan of er meer dan 1000 regio-artsen zijn. 
(3) (Ave UZKH: NEE’) 6 (Av e UZKHen | v(HA) | > 1000: ‘JA’) 


Dit is een voorbeeld van een ja/nee-vraag. 


Geef van elk E-tupel de a-waarde, de b-waarde en (onder de titel a) het pro- 
dukt van de c-, d- en e-waarde. 


(1) Ave U: {th {a,b} U {(a; t(c)* t(d)* t(e))} | te v(E)} 
(2) Ave U: {{(a; t@)), ©; t(b)), (a; t(c) * t(d) * t(e))} | te v(E)) 
Geef van alle medicijnverstrekkingen het patiéntnummer, de medicijncode 
en (onder de titel HOEV) de verstrekte hoeveelheid. 
(1) Ave UZKH: 
{t| {PNR, MCD} U {(HOEV; (AEK) * (FREQ) * t(DUUR))} 
| te v(MVS)} 
Als voorwaarde voor de keuze van a stellen we dat ag {a,b}. 
Onder (A) is het antwoord in elke toestand een tabel over {a , b, a}. 
Als {a , b} geen sleutel van E in U is (zoals in het voorbeeld onder (B) het 


geval is), dan geven de oplossingen per (a; b)-combinatie wel aan welke 
a-waarden er optreden, maar niet hoe vaak ze optreden. 


QUERIES 


K8: (A) 


(B) 


(C) 
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Geef elke A-combinatie die in de E-tabel voorkomt en (onder de titel B) het 

aantal keren dat die combinatie voorkomt. 

(1) Ave U: {wu {Q; | {te ve) le} A=w} 1)} Il we v(E) |A} 

Geef van elke behandelde patiënt het patiëntnummer en (onder de titel 

AANTBEH) het aantal keren dat die patiënt is behandeld. 

(1) Ave UZKH: {w U {(AANTBEH; | (te v(PB) | t| (PNR) =w}1)} 
| we v(PB) | {PNR}} 

Onder (A) stellen we als voorwaarde voor de keuze van B dat B ¢ A; het 

antwoord is in elke toestand een tabel over A U {B}. 

Wanneer we ook de niet behandelde patiënten genoemd willen zien dan 

moeten we w niet over v(PB) | {PNR} maar over v(PAT) | {PNR} laten 

"lopen". De vraag heeft dan evenwel betrekking op meer dan één tabel. 


O Voorbeeld 6.2. 


Bij de vragen in Voorbeeld 6.3 komen de gegevens weliswaar telkens uit slechts één tabel, 
maar wel op grond van criteria gebaseerd op andere tabellen. 


VOORBEELD 6.3: 


Kl: (A) Geef de A-waarde van ieder E-tupel waarvan de a-waarde tussen m en n ligt 


(inclusief m maar exclusief n) en waar ook een E’-tupel met dezelfde B- 
waarde bijhoort. 


(1) AveU:(thAlte v(E)enms§ t(a)ent(a) <nen 

dte v(E’):t’|} B=t} B} 
(2) Ave U: {tf Alte v(E)ent(a)2 ment(a) < nen 

O<1 {t'e WE’) It’) B=t} B} 1} 
(3) Ave U:({te v(E) | t(a)e [m..n)} PA) A 

((te v(E) | (te v(E) It) B=t} B} +} |A) 

(4) AveU:(tlAltev(Bent(aje [m..n)ent} Be v(E’) |B) 
(5) Ave U: (VE [| B) eX (te v(E) | tae [m..n)}) PA 
(6) Ave U: {th Alte v(E) D< (v(E’) | Ben t(a)e [m..n)} 
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Geef patiëntnummer, geboortedatum, inschrijfdatum en NAW-gegevens 
van alle in 1989 geboren patiëntjes die opgenomen zijn of opgenomen zijn 
geweest. 


(5) Ave UZKH: (W(OPN) | {PNR}) D< (te v(PAT) | ((GBD) e 
[19890101 … 19900101)}) | (PNR, GBD, INSD, NAW} 


Geef onder de titels a, B en y achtereenvolgens de a-, b- en c-waarde van 
elk E-tupel waarbij de d’-waarde van het bijbehorende E’-tupel volgens de 
DB-functie H groter dan w is. 


(1) Ave U: (((a; t(@)), (B; £(b)),  t(c))} 
| te v(E) en H(v) (t) (d’) >w} 

Geef onder de titels PATIENT, DATUM en LOCATIE achtereenvolgens 
het patiëntnummer, de datum van overplaatsing en het nieuwe ver- 
pleegruimtenummer van iedere overplaatsing gedurende een opname die na 
10 juni 1989 begon. 
(1) Ave UZKH: {{(PATIENT ; t(PNR)), 

(DATUM ; t(BDAT)), 

(LOCATIE; t(RNR))} 

| te v(OVR) en Hovropn(v) (t) (OPND) > 890610} 

We zien hier dus hoe we de heading van een resultaattabel zelf kunnen 
“verfraaien”. 
Wanneer we de in §4.3 gegeven definitie van de DB-functie Hovropn 
uitschrijven, dan komen we tot de volgende alternatieve formulering: 


Ave UZKH: {{(PATIENT ; t(PNR)), 
(DATUM ; «BDAT)), 
(LOCATIE; t(RNR))} 
| te v(OVR) en 
Ju e v(OPN): (PNR) = u(PNR) en 
t(BDAT) > u(OPND) en 
u(OPND) > 890610 en 
als u(ONTS) = ‘JA’ 
dan ((BDAT) S u(ONTD))} 


We zien hier duidelijk het nut van DB-functies bij het formuleren van 
queries. Dit is op zich niet zo verwonderlijk wanneer we bedenken dat DB- 
functies de formaliseringen zijn van de intuïtieve verbanden die er tussen 
de tabellen geacht worden te bestaan. 
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K3: (A) Geef de E-tupels die volgens de gegeneraliseerde compositie G © H naar 
zichzelf verwijzen (dus via de E’-tabel). 


(1) Ave U: {te vE)I(G OA)()(t)=2} 
(2) Ave U: {te v(E) 1 (Gv) oe HW) (t) = 28} 
(3) Ave U: {te v(E) | GW) (HWV) (t)) =t} 


(B) Geef de gegevens van alle afdelingen waarvan de chef een medewerker van 
diezelfde afdeling is. 


(1) Ave UZKH: (te v(AFD) | (Hmwafd © Hafdmw) (v) (t) =t} 

(C) Onder (A) vragen we voor elke toestand v dus naar de dekpunten van de 
functie (G © H) (v). 
We geven voor (B) ook nog een oplossing zonder DB-functies: 


àv e UZKH: {t e v(AFD) | 3ť e v(MW): (t’(IDNR) = t(CHNR) en 
t' (ANR) = t(ANR))} 


O Voorbeeld 6.3. 


In het volgende voorbeeld behandelen we enige vragen die met name ingaan op de situatie 
dat er een DB-functie G over U met betrekking tot het tabelindexpaar (E’ ; E) gegeven is. De 
vragen in Voorbeeld 6.4 zijn vaak kleine variaties van elkaar. We zullen hierbij zien hoe 
sommige oplossingen zich wel en sommige zich niet goed lenen voor simpele aanpassingen 
bij zulke kleine variaties. Deze aanpassingsproblemen bij kleine wijzigingen in de vraagstel- 
ling staan model voor die welke we bij talen als SQL kunnen tegenkomen. 


Voor de lezer die bekend is met CODASYL (zie bijvoorbeeld [CO 71], [O1 78] of [Re 82]) 
merken we op dat bij een gedisciplineerde aanpak in een klassieke CODASYL-omgeving de 
DB-functie G met behulp van een (AUTOMATIC MANDATORY) "DBTG set" kan worden 
geïmplementeerd. Hierbij dient dan wel in elke toestand v e U voor elke t’ € v(E’) als 
"owner" van t’ het E-tupel G(v) (t’) te worden gekozen. In dat geval representeert voor 
t e v(E) de tupelverzameling G(v) invt de verzameling "members" van t. In een dergelijke 
3© generatie-omgeving kunnen onze formele queries nu dienst doen als de formele 
specificaties van de te schrijven (COBOL-)programma’s. 


In Voorbeeld 6.4 geven we onder (C) enige additionele oplossingen in het geval dat 


Vve U:Vte WE): Vt’ e v(E): (GW) (’)=t <r ent zijn compatibel), (**) 
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een niet ongebruikelijke situatie in de praktijk. Zo geeft bijvoorbeeld Opgave 2.86 enige vol- 
doende voorwaarden opdat (**) geldt. We wijzen er verder op dat t’ en t compatibel zijn 
desda t| g(E) =t} g(E"). 


VOORBEELD 6.4: 


K1: (A) Geef alle E-tupels waar volgens G een E’-tupel bijhoort. 


(B) 


(C) 


K2: (A) 


(B) 


(1) Ave U: {te v(E)l dte v(E): GW) (t)=t) 

(2) Ave U: {te v(E) | {t e v(E) | GW) (t)=t} +} 
(3) Ave U: {te v(E) | (G(v) invt) #2} 

(4) Ave U:{(tev(E)l | GW) invt | #0} 

(5) Ave U: {te v(E)l | G(Ww)invt |2 1} 

Geef alle patiénten die wel eens zijn behandeld. 

(3) Ave UZKH: (te v(PAT) | (Hpbpat(v) inv t) # Ø} 
Als (**) geldt dan zijn ook de volgende oplossingen correct: 
(6) Ave U:(tev(E)laAtevE):t'\glE)=t| 2(E)) 
(7) Ave U: (ME) PA vE’) | gE) 

(8) Ave U: VE) PA VE’) | g(E)) 


Uitwerking van oplossing (6) voor de vraag onder (B) levert als resultaat: 
(6) Ave UZKH: (te v(PAT) | Jt’ e v(PB) : t’(PNR) =t(PNR)} 
Terzijde merken we op dat de eerste vijf oplossingen het functionele ver- 
band tussen de tabellen benadrukken, oplossing (6) in de stijl van de rela- 
tional calculus is geschreven, en de oplossingen (7) en (8) binnen het kader 


van de relational algebra passen. Voor nadere uitleg van deze drie termen 
verwijzen we de lezer naar [Sh 81] en [Co 72b]. 


Geef alle E-tupels waar volgens G geen E’-tupel bijhoort. 
(1) Ave U: {te vwE)I Yt e v(E): GW) (t) #6} 

(2) Ave U: {te vE) | (te v(E) | GW) (t) =t} =} 
(3) Ave U: {te v(E) | (G(v) invt) =} 

(4) Ave U: {te v(E)| | Gi) invt | =0} 

(5) Ave U: {te v(E)! | Gv) invt | <1} 


Geef alle behandelingen die nooit zijn uitgevoerd. 
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(4) Ave UZKH: (te v(BEH) | | Hpbbeh(y) invt | =0} 
(C) Als (**) geldt dan zijn ook de volgende oplossingen correct: 

(6) Ave U: {te v(E) I Vt’ e ve’): t’} g(E)#t} g(E)} 

(7) Ave U: v(E)- (ME) PA vE’) | (E) 

(8) Ave U:v(E)- (ME) PA vE’ | E) 


K3: (A) Geef alle E-tupels waar volgens G ten minste drie E’-tupels bijhoren. 
(1) Ave U: {te v(B)lJtev(E):At'e v(E): At" e WE): 
GW) (t/’)=t en GW) (t”)=t en GW) (t)=t 
cht et enter” arar) 


(2) Ave U: {te v(E) | | Gi) invt |2 3} 
(B) Geef de gegevens van alle afdelingen met ten minste drie medewerkers. 
(2) Ave UZKH: (te v(AFD) | | Hmwafd(v) invt | = 3} 


(C) Het analogon van oplossing (6) onder K1 in het geval dat (**) geldt, wordt 
(in Opgave 6.3) aan de lezer overgelaten. 
De oplossingen (7) en (8) onder K1 lenen zich niet voor rechtstreekse aan- 
passing aan de vraagstelling onder K3. 


K4: (A) Geef alle E-tupels waar volgens G een E’-tupel met d’-waarde w’ bijhoort. 
(1) Ave U: {te v(E) 1 Ate (GQ) invt) : t’(d’)=w’} 
(2) Ave U: {te v(E) | {t e (G(v) invt) | ’(d’))=w’} # 3} 
(3) Ave U: {te v(E)| I{t’ e (Gv) invt) | £(d') =wW'}|I 21} 
(4) Ave U: {te v(E)l we {t’'(d’) | te (G(v) inv t)}} 
(B) Geef de gegevens van alle opnamen gedurende welke er een overdracht aan 
specialist 129 plaatsvond. 
(1) Ave UZKH: (te v(OPN) | Jt’ e (Hospopn(v) inv t) : t’(IDNR) = 129} 
(C) Als (**) geldt dan zijn bijvoorbeeld ook de volgende oplossingen correct: 
(5) Ave U:{(tev(E)l 3t e ve’): (1) g(E)=t| gE’) ent’(d’)=w’)} 
(6) Ave U:WE PA (te vE’ | t(d) =w'}) | 8E) 
(7) Ave U: (te v(E) pd vE’) | t’(d’)=w’} | g(E) 
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K6: (A) 


(B) 
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Voor de DB-functie Hospopn in ons voorbeeld onder (B) geldt (**) niet. 
Uitwerking van deze DB-functie levert het volgende resultaat op (zie de 
definitie in §4.3): 


Ave UZKH: (te v(OPN) | Jt’ e v(OSP) : (t (IDNR) = 129 en 
t’(PNR) = (PNR) en 
t(OPND) < t’(BDAT) en 
als t(ONTS) = ‘JA’ 
dan t’(BDAT)< t(ONTD))} 


Geef alle E-tupels waar volgens G een E’-tupel met een andere d’-waarde 
dan w’ bijhoort. 
(1) Ave U: {te vE) 1 Af e (GW) invt): t’'(d’) 4w’} 
(2) Ave U: {te v(E) | {t e (GW) invt) | (d) #w'} +O} 
(3) Ave U: {te v(E) I ({t’(d’/) |t € (Gv) inv t)} — {w} # 5} 
Geef de SP-gegevens van elke specialist die wel eens wat anders dan een 
medicijn met code ‘ASPRO’ heeft voorgeschreven. 
(2) Ave UZKH: (te v(SP) | {t’ e (Hmvssp(v) inv t) | 

t' (MCD) + ‘ASPRO’ } # Ø} 
Als (**) geldt dan zijn bijvoorbeeld ook de volgende oplossingen correct: 
(4) Ave U:(v(E)D< {t e v(E’) | t’(d’) #w’}) | gE) 
(5) Ave U: {t’e v(E) pd v(E’) | t’(a’) +w} | 8E) 
De ervaring heeft ons geleerd dat er op de vraag "Geef alle E-tupels waar 
volgens G geen E’-tupel met d’-waarde w’ bijhoort” (ten onrechte) vaak een 


oplossing behorende bij de klasse K5 wordt gegeven. In Opgave 6.4 komen 
we op deze vraag terug. 


Geef alle E-tupels waar volgens G in de E’-tabel wel de d’-waarden x , x’ 
en x” maar niet de d’-waarden y en y’ bijhoren. 
(1) Ave U: {te v(E) 1 {t’d’) |t e (GW) inv) A 

(x, x’, x”, y y} = (x, x, x”) } 
Geef de gegevens van elke patiënt die wel de behandelingen K1, K3 en K5 
maar niet de behandelingen K2 en K4 heeft ondergaan. 
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(1) Ave UZKH: (te v(PAT) | (£(BCD) | t’ e (Hpbpat(y) inv £)} N 
KI *K2’. ‘K3’, ‘K4’, ‘KS’ } KI, ‘K3’, ‘KS’ }} 
O Voorbeeld 6.4. 


Bij de vragen in Voorbeeld 6.5 zijn de gegevens in het antwoord afkomstig van verschil- 
lende tabellen tegelijk. Gezien het ad hoc karakter van zulke vragen zullen we in Voorbeeld 
6.5 geen algemene vormen geven maar ons beperken tot specifieke vragen over UZKH (V1, 
V2, etcetera). 


VOORBEELD 6.5: 


VI: Geef alle persoonsgegevens van alle verplicht verzekerde leden van het niet- 
medisch personeel. (Onder "alle persoonsgegevens” verstaan we in dit geval alle 
MW-, WN-, NMP- en VV-gegevens.) 


(1) Ave UZKH: v(MW) pq v(WN) pq v(NMP) pq v(VV) 


Bij differentiatie en generalisatie - zie Hoofdstuk 3 - raken de gegevens van één 
"object" gewoonlijk verspreid over diverse tabellen. Reconstructie van al die 
verspreide objectgegevens kan meestal geschieden met behulp van joins (zoals 
geïllustreerd in dit voorbeeld). 


V2: Geef van elke behandeling op 10 november 1986 waarbij noch de behandelende 
specialist, noch de assistent-specialist is verbonden aan de afdeling waarin de 
behandeling plaatsvond: behandelcode en volgnummer en van de patiënt het 
nummer, de NAW-gegevens en de geboortedatum. 


(1) Ave UZKH: {t} (BCD, VNR} U Hpbpat(v) (£)) (PNR, GBD, NAW} 
| te v(PB) en t¢(BDAT) = 861110 en 
(Hspmw © Hpbsp) (v) (t) (ANR) + Hpbru(v) (t) (ANR) en 
(Hspmw © Hpbspa) (v) (t) (ANR) + Hpbru(v) (t) (ANR)} 
(2) Ave UZKH: {t} (BCD, VNR} U r'| (PNR, GBD, NAW} 
| (t; t’) e v(PB) x v(PAT) en 
t(PNR) = t’(PNR) en t(BDAT) = 861110 en 
dre v(RU):dme v(MW): Am’ e v(MW): 
[7(RNR) = (RNR) en m(IDNR) = t(IDNR) en 
m’(IDNR) = t(ASNR) en m(ANR) # r(ANR) en 
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m’(ANR) + r(ANR)]} 
(3) Ave UZKH: {t | te v(PB) pq v(PAT) ent(BDAT) = 861110 en 
Vr e v(RU) : Vm e v(MW): Vm’ e v(MW): 
[ als r(RNR) = (RNR) en m(IDNR) = t(IDNR) en 
m’(IDNR) = t(ASNR) 
dan m(ANR) # r(ANR) en m’(ANR) # r(ANR)] 
} | (BCD, VNR, PNR, GBD, NAW} 


Bij oplossing (1) maken we dankbaar gebruik van de in §4.3 gedefinieerde DB- 
functies; oplossing (2) staat echter dichter bij een mogelijke oplossing in SQL. 


De "s-oplossing" onder (2) en de "V-oplossing" onder (3) zijn equivalent omdat 
{RNR} en {IDNR} sleutels van RU respectievelijk MW in UZKH zijn! 


Geef onder de titels AANVANG, NUMMER, NAAM en AANTAL van alle 
opnamen die in juni 1989 eindigden achtereenvolgens de aanvangsdatum, het 
nummer en de naam van de betreffende patiént, en het aantal verschillende afde- 
lingen waarop de betreffende patiént gedurende die opname heeft gelegen. 


(1) Ave UZKH: 
{{(AANVANG ; (OPND)), 
(NUMMER ; ¢(PNR)), 
(NAAM __ ; Hopnpat(») (t) (NAW) (NM)), 
(AANTAL ; | {Hopnru(v) (t) (ANR)} u 
{Hovrru(v) (u) (ANR) | u e Hovropn(v) inv t}1)} 
| te v(OPN) en t(ONTD) div 100 = 8906 en t(ONTS) = ‘JA’ } 
(2) Ave UZKH: 
(AANVANG ; t(OPND)), 
(NUMMER ; t(PNR)), 
(NAAM _ ; (NAW) (NM)), 
(AANTAL ; | {r(ANR) | re v(RU) en [ (RNR) =7(RNR) of 
du e (Hovropn(v) inv t) : (RNR) = r(RNR)]}1)} 
| (t; t^) e v(OPN) x v(PAT) en t(PNR) =t’(PNR) en 
890601 < t(ONTD) en t(ONTD) < 890701 en t(ONTS) = ‘JA’ } 


Evenals bij oplossing (3) van vraag V2 is ook hier een oplossing met behulp van 
een join (in plaats van een cartesisch produkt) mogelijk. Daarnaast zouden we de 
DB-functie Hovropn in oplossing (2) nog kunnen wegwerken. We verwijzen in 
dit verband naar Opgave 6.8. 
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V4: Geef het zogeheten verpleegkundige verslag van de (eventuele) opname van 
patiént 123210 begonnen op 10 juli 1989. (Onder het verpleegkundige verslag 
van een Opname verstaan we in ons ziekenhuis van Hoofdstuk 4 een tabel over 
{VANAF, BEVINDINGEN} die van elke periode waarin de opname door even- 
tuele overplaatsingen verdeeld is, de ingangsdatum en de verpleegkundige bevin- 
dingen tijdens die periode bevat.) 


(1) Ave UZKH: 
{{(VANAF; t(OPND)), (BEVINDINGEN; «(BEV))} 
| te v(OPN) en (PNR) = 123210 en t(OPND) = 890710} U 
{{(VANAF; ((BDAT)), (BEVINDINGEN; (BEV))} 
| te v(OVR) en t(PNR) = 123210 en 
Hovropn(v) (£) (OPND) = 890710} 


Als er geen opname van patiënt 123210 op 10 juli 1989 bestaat in toestand v, dan 
is volgens bovenstaande definitie het verpleegkundige verslag kennelijk de lege 
tabel (ongeacht de vraag of er eigenlijk wel een patiënt met nummer 123210 be- 
staat). Als zo’n opname wel bestaat en er n overplaatsingen zijn (met n 2 0), dan 
is het aantal tupels in het verpleegkundige verslag kennelijk n + 1. 


V5: In ons ziekenhuis noemen we een patiéntbehandeling(stupel) x een directe aan- 
gever van eventuele besmettingen voor een patiëntbehandeling(stupel) y dan en 
slechts dan als x vóór of op dezelfde dag als y plaatsvindt en x met y de behan- 
delde patiënt of iemand van het behandelteam (dat wil zeggen behandelend spe- 
cialist plus eventuele assistent-specialist) gemeen heeft. In het bijzonder is elk 
patiëntbehandelingstupel een directe aangever voor zichzelf. 

We definiëren nu voor elke v e UZKH de relatie DA, als de verzameling geor- 
dende paren (x ; y) waarvoor x in toestand v een directe aangever voor y is: 


DA, = {(x; y) | (x; y) € v(PB) x v(PB) en x(BDAT) S y(BDAT) en 
[x(PNR) = y(PNR) of 
{x(IDNR) , x(ASNR)} A {y(DNR), y(ASNR)} # 2]} 


Merk op dat DA, reflexief is, dat wil zeggen dat id(v(PB)) c DA,. 


Door een ongelukje op 8 september 1988 zijn mogelijk alle specialisten van 
afdeling 9 besmet geraakt. We willen daarom van elke patiént die als gevolg 
daarvan op directe of indirecte wijze via een behandeling besmet kan zijn 
geraakt, behalve het patiëntnummer, de NAW-gegevens en de bloedgroep ook 
het identiteitsnummer en de naam van de contactpersoon van de woonplaats van 
die patiënt weten. 
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We kunnen deze query over UZKH, die recursief van aard is, als volgt formeel 
weergeven: 


Xv € UZKH: 
{t | {PNR, NAW, BLGR} U 
{(CPRS ; £(IDNR)), (NAAM; t’(NAW) (NM))} 
| (t; t^) e v(PAT) x v(MW) en 
t’(IDNR) = Hpatplr(v) (t) (CPRS) en 
A(x; y)e Tcl(DA,) : (PNR) = t(PNR) en x(BDAT) 2 880908 en 
{x(IDNR) , x(ASNR)} © {m(IDNR) | m e v(MW) en m(ANR) = 9} #2)} 


We hebben bij deze recursieve query gebruik gemaakt van Tcl(DA,), de transi- 
tieve afsluiting van de relatie DA,; zie Definitie 0.22(a). 


O Voorbeeld 6.5. 


In Voorbeeld 6.6 gaan we in op vragen waarvan het antwoord gewoonlijk uit meer dan 
alleen maar één enkele tabel bestaat. Dergelijke vragen kunnen we tegenkomen in de sfeer 
van (week)overzichten, (maand)rapporten, (jaar)verslagen, dossiers en database-dumps 
bijvoorbeeld. Ook zogeheten external schema's of subschema’s kunnen we op deze wijze 
formeel behandelen. 


VOORBEELD 6.6: 
Onder K2 maken we gebruik van het begrip "deelskelet". We noemen g’ een deelskelet 
van het DB-skelet g desda g’ een verzamelingsfunctie is en dom(g’) < dom(g) en 
VE e dom(g’): g’(E) c g(E). Dus een deelskelet van g is een DB-skelet waarvan elke 
tabelindex tevens een tabelindex van g is, en wel zodanig dat alle attributen van die 
tabelindex volgens dat deelskelet ook attributen van die tabelindex volgens g zijn. 


Als voorbeeld definiéren we het voor de afdeling Personeelszaken relevante deelskelet 
PZS van het in Hoofdstuk 4 gebruikte DB-skelet GZKH als volgt: 


PZS = GZKH} {MW, WN, MP, NMP, VV} 
U {(SP; GZKH(SP) — (LOC, ABD})} 


Dus het deelskelet PZS bestaat uit de tabelindexen MW, WN, MP, NMP, VV en SP 
met haast alle bijbehorende attributen; alleen de attributen LOC en ABD van de tabel- 
index SP doen niet mee. 


QUERIES 


K1: (A) 


(B) 


(C) 


K2: (A) 


(B) 


(C) 


K3: (A) 


(B) 
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Geef de gehele database-toestand. (Dit wordt wel een dump van de database 
genoemd.) 


(1) Ave U:y 
(2) id(U) | 


Geef alle gegevens in onze ziekenhuis-database. 
(2) id(UZKH) 


Een praktische toepassing van deze overigens vrij triviale query vormt het 
maken van "back-ups". 


Geef alle gegevens volgens het deelskelet g’, het zogenaamde subschema 
volgens g’. 


(1) Ave U: (AE e dom(g’): v(E) | gE) 


Geef alle gegevens volgens het deelskelet PZS. 


Ave UZKH: v| (MW, WN, MP, NMP, VV} 
U {(SP; v(SP)# (LOC, ABD})} 


Als g’(E) = g(E) voor alle E in dom(g’), dan kunnen we de oplossing onder 
(A) vereenvoudigen tot 


(2) Ave U: vl dom(g’) 


Onze oplossing onder (B) is mede gebaseerd op bovenstaande eigenschap. 


Geef voor alle tabelindexen met het attribuut a alle tupels waarvan de a- 
waarde w is (exclusief die a-kolom zelf). 
(1) Ave U: {(E; {tt {a} | te v(E) ent(a)=w}) 

| E e dom(g) ena e g(E)} 
(2) Ave U:(AEe dom(g) ena e g(E): (te v(E) | t(a)=w}} {a}) 
Geef alle persoonlijke en medische gegevens van patiént 177912 (exclusief 
het patiëntnummer zelf). 


(1) Ave UZKH: ((E; {t+ {PNR} | te v(E) en t(PNR) = 177912}) 
| E e (PAT, MVS, PB, OPN, ONT, OSP, OVR}} 
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(C) 


K4: (A) 


(B) 


(C) 
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Merk op dat het antwoord bij K3 altijd een DB-toestand is over het deel- 
skelet 


{(E; g(E)-— {a}) | E e dom(g) ena e g(E)}. 


Desondanks is K3 echter geen speciaal geval van K2, en wel omdat bij K2 
alle tupels meedoen terwijl er bij K3 ook nog een selectie plaatsvindt. 


Geef in een tabel over {ENTITEIT, AANTAL} een overzicht van alle 
tabelindexen met het bijbehorende aantal elementen. 


(1) Ave U: {{(ENTITEIT; E), (AANTAL; | v(Z)1)} | E e dom(g)} 


Geef in een tabel over (ENTITEIT, AANTAL} een overzicht van alle 
tabelindexen met het bijbehorende aantal elementen in onze ziekenhuis- 
database. 


(1) Ave UZKH: (((ENTITEIT; E), (AANTAL; | v(Z)1)} 
| E e dom(GZKH)} 


Merk op dat deze vraag deels over het DB-skelet (de "structuur") en deels 
over de DB-toestand (de "inhoud") gaat. 


O Voorbeeld 6.6. 


Met de voorgaande, gevarieerde selectie van voorbeelden hebben we een indruk willen 
geven van de vele soorten van vragen die gesteld kunnen worden en van de manier(en) 
waarop die vragen formeel gespecificeerd kunnen worden. 


Wat bij onze voorbeelden misschien ook al enigszins naar voren komt en in de praktijk 
meestal in nog veel sterkere mate het geval zal zijn, is dat zelfs bij zorgvuldige formulering 
van een vraag in natuurlijke taal de precieze betekenis van de vraag toch nog niet altijd 
duidelijk is. Ook is het niet ongebruikelijk dat een vraag bij nader inzien zelfs voor meer dan 
één uitleg vatbaar is. Bovendien laat de zorgvuldigheid van de formulering van de vraag zelf 
ook vaak nog te wensen over. In die gevallen is nader overleg met de vragensteller dan ook 


onontbeerlijk. 
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OPGAVEN 


6.1. Geef de volgende vragen en opdrachten over het DB-universum UZKH uit Hoofdstuk 
4 formeel weer. 


(a) Geef nummer en naam van elke afdeling waarin in 1987 geen patiéntes uit 
Waalre werden behandeld. 


(b) Zijn er afdelingen waarin in 1987 geen patiëntes uit Waalre werden behandeld? 
(c) Is het waar dat er meer niet-medisch dan medisch personeel is? 


(d) Geef nummer en naam van alle specialisten die chef zijn van de afdeling waaraan 
ze formeel verbonden zijn en bovendien maximaal drie verschillende soorten 
behandelingen hebben verricht (als behandelend specialist dan wel als assistent- 
specialist). 

(e) Geef alle persoonsgegevens van alle contactpersonen die minstens twee plaatsen 
vertegenwoordigen waar meer dan 100 ingeschreven patiënten wonen. (Onder 
“alle persoonsgegevens" verstaan we in dit geval alle MW-, WN- en NMP- 
gegevens plus eventuele VV-gegevens.) 

Hint: gebruik de outer join, gedefinieerd in Opgave 2.93. 


(f) Geef het totaal geprognosticeerde aantal behandelingen voor het lopende jaar. 


(g) Geef het totaal aantal ligdagen in oktober 1987. (Het aantal ligdagen van een 
opname is het aantal dagen dat die opname heeft geduurd, inclusief de dag van 
opname en de dag van ontslag.) 


(h) Geef van elke kinderloze patiënte geboren in en wonende te Dodewaard het be- 
knopte medische dossier (zoals gedefinieerd in Opgave 4.12). 
Hint: gebruik de in Opgave 4.12 ingevoerde uitdrukking BMD voor het beknopte 
medische dossier. 


(i) Geef in een tupel over {OPNAMEN, BEHANDELINGEN, MEDICIJNEN) het 
totaal der factuurbedragen gesommeerd over alle Eindhovense patiëntes die in 
1989 werden ingeschreven, uitgesplitst naar opnamen, patiëntbehandelingen en 
medicijnverstrekkingen. 

G) Geef het totaal van alle factuurbedragen over alle Eindhovense patiëntes die in 
1989 werden ingeschreven. 


(k) Geef in een tabel over (GESLACHT, BEHANDELINGEN) per geslacht de 


totale patiëntbehandelingskosten (= factuurbedragen) van alle Eindhovense 
patiënten die in 1989 werden ingeschreven. 
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6.3. 


6.4. 


6.5. 


6.6. 


6.7. 


6.8. 
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Geef de volgende queries over UZKH in de vorm van een vraag of een opdracht weer. 
(a) Ave UZKH: (te v(MVS) | t(PNR) = 256896} | (MCD, DAT} 
(b) (Ave UZKH: ‘JA’) 6 
(Ave UZKH en v(AFD) | {ANR} c v(RU) | (ANR) : NEE’) 
(c) Ave UZKH: (te v(SP) | Vt’ e (Hpbsp(v) inv t): 
| {u e (Hpbsp(v) inv t) | u(BCD) = t’(BCD)}1 < 5} 
(d) Ave UZKH: (Xt e v(MED) : (t(VRD) * t(VKPR)) div 100) 


Geef voor de vraag onder K3 van Voorbeeld 6.4 het analogon van oplossing (6) onder 
K1 in het geval dat (**) geldt. 


Geef de vraag "Geef alle E-tupels waar volgens G geen E’-tupel met d’-waarde w’ 
bijhoort" formeel weer. (Zie voor de context van de vraag de klasse K5 van Voorbeeld 
6.4.) 


Geef ook de vraag "Geef alle E-tupels waarbij volgens G in de E’-tabel geen enkele 
d’-waarde meer dan vijf keer voorkomt" formeel weer. 


Geef de volgende vraag, die van dezelfde situatie uitgaat als Voorbeeld 6.4, formeel 
weer. 

Geef alle E-tupels die volgens G in de E’-tabel ten minste alle d’-waarden hebben die 
het (eventuele) E-tupel to ook heeft. 


Deze opgave is een uitbreiding van K4 van Voorbeeld 6.6. We willen nu niet alleen 
een overzicht van alle tabelindexen met het bijbehorende aantal elementen maar daar- 
naast (in een tabel over (ENTITEIT, ATTRIBUUT, AANTAL }) ook een overzicht van 
alle attributen met het aantal verschillende waarden dat er voor dat attribuut in de 
betreffende tabel optreedt. Het totale antwoord dient daarbij te worden opgevat als een 
(tabelwaardige) functie over (ENTITEITEN, ATTRIBUTEN}. 


Geef voor vraag V3 in Voorbeeld 6.5 een oplossing door in de daar gegeven oplossing 
(2) het cartesisch produkt te vervangen door een join en de DB-functie Hovropn weg te 
werken (met behulp van de definitie in §4.3). 
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6.9. (a) Geef voorpe IN en de DATVZ een formele definitie van de functie VPV(p,d) 
over UZKH die aan elke v e UZKH toevoegt het in vraag V4 van Voorbeeld 6.5 
omschreven verpleegkundige verslag van de (eventuele) opname op datum d van 
de patiënt met patiéntnummer p. 


(b) Geef voor p € IN een formele definitie van de functie VPVS(p) over UZKH die 
aan elke v e UZKH een tabel over (OPNDAT, VERSLAG} toevoegt waarin de 
opnamedatum en het verpleegkundige verslag van elke opname van de (even- 
tuele) patiënt p voorkomt. Maak hierbij gebruik van de functie VPV(p‚d) uit 
onderdeel (a). 


6.10. In ons ziekenhuis van Hoofdstuk 4 wordt onder het dossier van een opname verstaan 
een functie over {OPNGEG, OSPGEG, PBGEG} met als waarden achtereenvolgens 
het opnametupel in kwestie, de verzameling van alle overdrachtstupels behorende bij 
die opname en, ten slotte, de verzameling van alle behandelingstupels van de betref- 
fende patiënt tijdens die opname (behandelingen op opname- of ontslagdatum moeten 
worden uitgesloten). Geef nu de volgende opdracht over UZKH formeel weer: 


Geef alle opnamedossiers van patiënt 123453. 


6.11. In ons ziekenhuis van Hoofdstuk 4 wil men voor elke maand van elk van de jaren 1960 
tot en met 1988 het totaal der factuurbedragen weten - het totaal naar beneden afgerond 
op hele guldens - van de ontslagen die die maand plaatsvonden. Echter, sommigen 
willen als antwoord een tabel (met 30 attributen en 12 elementen) zoals gepresenteerd 
in Figuur 6.1(a), en sommigen willen als antwoord een tabel (met 13 attributen en 29 
elementen) zoals gepresenteerd in Figuur 6.1(b). 


Figuur 6.1 


Geef elk van de beide wensen als een query over UZKH weer. 
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6.2 VIEWS 


Wanneer een bepaalde query herhaaldelijk zal worden toegepast in een organisatie, dan kan 
het nuttig zijn die query van een naam te voorzien en in het vervolg die naam te gebruiken 
(in plaats van de query telkens opnieuw te specificeren). Zo’n "named query" wordt wel een 
view genoemd (omdat het zogezegd een "zicht op de database" is). Formeel beschouwen we 
een view als een geordend paar waarvan de tweede coordinaat een query is: 


DEFINITIE 6.2: 

Als U een verzameling is, dan: 

p is een view op U <> p is een geordend paar en 
1 (p) is een query over U. 


Als p een view is, zeg p = (n ; q), dan noemen we n wel de naam van p en q wel de definitie 
van p. 


Omdat in de praktijk verschillende queries niet een ad hoc karakter hebben maar regelmatig 
opnieuw toegepast worden, willen we gewoonlijk een hele verzameling queries "inblikken" 
in de vorm van views. Voorwaarde hierbij is wel dat de namen van de views onderling ver- 
schillend zijn. Anders gezegd, zo’n verzameling van views dient een functie te zijn. Zo’n 
functie die aan viewnamen de bijbehorende queries over U toevoegt, noemen we wel een 
viewstelsel op U: 


DEFINITIE 6.3: 
Als U een verzameling is, dan: 
Vis een viewstelsel op U <> V is een functie en 
Ype V : pis een view op U. 


Een alternatieve verwoording is dat V een viewstelsel op U is desda V een functie is en 
Vn e dom(V) : V(n) is een query over U. 


VOORBEELD 6.7: 


We definiéren een viewstelsel VS1 op het DB-universum UZKH uit Hoofdstuk 4. Het 
viewstelsel bestaat uit zeven views. De viewnamen zijn characterstrings. De queries 
zijn voor een deel ontleend aan de voorbeelden in §6.1. 


De views hebben de volgende namen en informele omschrijvingen: 
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“VOORRAADOVERZICHT’ : code, naam en voorraad van alle medicijnen (zie 
Voorbeeld 6.2, K2(B)). 


‘AFDELINGEN’ : de afdelingsgegevens inclusief het aantal werknemers 
per afdeling. 
‘PATIENTKOSTEN’ : van elke Eindhovense patiënt die in 1989 werd 


ingeschreven, het patiëntnummer, de naam, de 
geboortedatum, het geslacht en het totaal der factuur- 
bedragen, dit laatste uitgesplitst naar opnamen, behan- 
delingen en medicijnverstrekkingen. 


‘KWARTAALKOSTEN’ : het totale bedrag aan uit te betalen inkomensbe- 
standdelen per kwartaal (op basis van de huidige 
bedragen). 

‘PZVIEW’ : het voor de afdeling Personeelszaken relevante 
subschema (zie Voorbeeld 6.6, K2(B)). 

‘DBDUMP’ : de gehele database-toestand (zie Voorbeeld 6.6, K1). 

‘DBSIZE’ : overzicht van alle tabelindexen met het bijbehorende 


aantal elementen (zie Voorbeeld 6.6, K4). 


De definitie van ons viewstelsel VS1 op UZKH luidt nu als volgt: 


VSI = {(‘VOORRAADOVERZICHT?’ ; 
Av e UZKH : v(MED) | (MCD, MNM, VRD}), 
(‘AFDELINGEN’ ; 
Ave UZKH: {aU ((WNAANTAL; 
| {m e v(MW) >< v(WN) | m(ANR) = a(ANR)}1)} 
| a e v(AFD)}), 
(‘PATIENTKOSTEN’ ; 
Ave UZKH: (((NUMMER ; p(PNR)), 
(NAAM ; P(NAW) (NM)), 
(GEBDAT _ ; p(GBD)), 
(GESLACHT; p(GESL)), 
(OPNBEDR ; Zt € v(ONT) en t(PNR) =p(PNR) : t(BEDR)) , 
(BEHBEDR ; Èt e v(PB) en t(PNR)=p(PNR): t(BEDR)) , 
(MVSBEDR ; Zt e v(MVS) en ¢(PNR) =p(PNR) : t((BEDR))} 
| p e v(PAT) en p(INSD) div 10000 = 89 en 
p(NAW) (WPL) = ‘Eindhoven’ }) , 
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(‘KWARTAALKOSTEN’ ; 
Av e UZKH: 13 * (Èt e v(SP) en (IND) = ‘JA’ : (HONU) * t(AUW)) 
+3 * (Xt e v(WN): t(SAL)) * 100 
+3 * (Xt e v(NMP): t(VERG)) * 100), 
(‘PZVIEW’; 
Ave UZKH:v} (MW, WN, MP, NMP, VV} U 
{(SP; v(SP) | (LOC, ABD})}), 
(‘DBDUMP’ ; 
id(UZKH)) , 
(‘DBSIZE’ ; 
Ave UZKH: {{(ENTITEIT; E), 
(AANTAL ; | v(E)1)} 
| E e dom(GZKH)}) }. 


Nu het viewstelsel VS1 eenmaal gegeven is, kunnen we er vervolgens bij het formu- 
leren van nieuwe queries gebruik van maken. Als voorbeeld bekijken we de opdracht 
"Geef nummer, naam en totaal der factuurbedragen van elke in 1989 ingeschreven 
patiënt uit Eindhoven aan wie al voor meer dan een ’vuurtoren’ aan medicijnen is ver- 
strekt". Met behulp van VS1 kunnen we de bijbehorende query eenvoudig als volgt 
specificeren: 


Av e UZKH: {t| (NUMMER, NAAM} U 
{((TOTAAL ; t(OPNBEDR) + t(BEHBEDR) + t(MVSBEDR))} 
| te VS1(‘PATIENTKOSTEN’) (v) en t(MVSBEDR) > 25000} 


Zonder de hulp van VS1 is de query duidelijk minder eenvoudig te formuleren: 


Av e UZKH: { { (NUMMER; p(PNR)), 
(NAAM _ ;p(NAW)(NM)), | 
(TOTAAL ;Xte v(ONT) U v(PB) U v(MVS) en 
t(PNR) = p(PNR) : t(BEDR))} 
| p e v(PAT) en p(INSD) div 10000 = 89 en 
p(NAW) (WPL) = ‘Eindhoven’ en 
(Zt e v(MVS) en t(PNR) = p(PNR) : t(BEDR)) > 25000} 


O Voorbeeld 6.7. 


We merken op dat de views genaamd ‘DBDUMP’ en ‘DBSIZE’ in VS1 van zo’n algemeen 
karakter zijn dat ze bij een DBMS in feite standaard geleverd zouden moeten worden. 
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Een view (n;q) kan ook worden opgevat als een “kennisregel" waarbij n dan het te 
definiëren "begrip" is en q de definitie van dat begrip. Een duidelijk voorbeeld hiervan is de 
(voor de salarisadministratie bestemde) view genaamd ‘KWARTAALKOSTEN’ in VSI, 
waarin nauwkeurig de gedetailleerde kennis is vastgelegd welke ingrediënten (in welke 
verhoudingen) de totale salariskosten per kwartaal bepalen. Met behulp van views kan 
zodoende een hele “bibliotheek” van afleidbare begrippen worden opgebouwd rondom een 
database-universum. Omdat een database-managementsysteem per gedefinieerd database- 
universum vaak meer dan één viewstelsel toestaat, bijvoorbeeld één viewstelsel per 
gebruiker of gebruikersgroep, kunnen er meestal zelfs verschillende soorten bibliotheken 
worden aangelegd. 


Met ons ruime viewbegrip modelleren we niet alleen de SQL-views ([SQL 897), waarvan de 
view genaamd “VOORRAADOVERZICHT’ in VS1 een typisch voorbeeld is, maar model- 
leren we tevens de ANSI/SPARC external views ([TK 78]), getuige bijvoorbeeld de view 
genaamd ‘PZVIEW’ in VSI. 


Het kan in de praktijk nuttig zijn om bij het definiëren van nieuwe views gebruik te maken 
van reeds eerder gedefinieerde views (zoals ook in de opgaven zal blijken). De meeste 
database-managementsystemen bieden deze mogelijkheid dan ook, zie bijvoorbeeld Kijkgat 
6 in [IDT 88]. 


OPGAVEN 


6.12. Geef de volgende opdrachten over het DB-universum UZKH uit Hoofdstuk 4 formeel 
weer, voorzie ze van een naam en leg ze vast in een viewstelsel VS2 op UZKH. 
Hoewel sommige van deze opdrachten reeds in Opgave 6.1 voorkwamen, wordt u 
geacht nu gebruik te maken van het viewstelsel VS1 gedefinieerd in Voorbeeld 6.7. 


(a) Geef in een tupel over (OPNAMEN, BEHANDELINGEN, MEDICIJNEN) het 
totaal der factuurbedragen gesommeerd over alle Eindhovense patiëntes die in 
1989 werden ingeschreven, uitgesplitst naar opnamen, patiëntbehandelingen en 
medicijnverstrekkingen. 


(b) Geef het totaal van alle factuurbedragen over alle Eindhovense patiëntes die in 
1989 werden ingeschreven. 


(c) Geef in een tabel over (GESLACHT, BEHANDELINGEN) per geslacht de 
totale patiëntbehandelingskosten van alle Eindhovense patiënten die in 1989 wer- 
den ingeschreven. 
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6.13. 


6.14. 
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(d) Geef de gemiddelde kwartaalkosten per (in dienst zijnde) medewerker, naar 
beneden afgerond op hele guldens. 


Leg de volgende opdrachten over het DB-universum UZKH uit Hoofdstuk 4 (met 
zelfgekozen namen) vast als views in een viewstelsel VS3 op UZKH. Gebruik hierbij, 
voor zover mogelijk, de viewstelsels VS1 uit Voorbeeld 6.7 en VS2 uit de vorige 
opgave. 


(a) Geef in een tabel over (GESLACHT, BEHANDELINGEN) voor de twee 
geslachten de onderlinge percentages van de totale patiëntbehandelingskosten 
van alle Eindhovense patiënten die in 1989 werden ingeschreven (naar beneden 
afgerond op tienden van procenten). 


(b) Geef van elk medisch personeelslid het identiteitsnummer, de naam, het salaris 
en het verschil ten opzichte van de gemiddelde kwartaalkosten per in dienst 
zijnde medewerker (positief als het salaris meer dan het gemiddelde is en negatief 
als het minder is). 


(c) Geef in een tabel over {1, 2} alle patiëntbehandelingsparen waarvan de eerste 
patiëntbehandeling een directe aangever van eventuele besmettingen voor de 
tweede is (in de zin van Voorbeeld 6.5, V5). 

Hint: zie ook Opgave 1.13. 


Leg de volgende opdrachten over UZKH, die zijn gebaseerd op vraag V5 van Voor- 
beeld 6.5, met zelfgekozen namen vast als (recursieve) views in een viewstelsel VS4 
op UZKH. U mag hierbij gebruik maken van de eerder gedefinieerde viewstelsels. 


(a) Geef de patiëntgegevens van alle patiënten die op directe of indirecte wijze via 
een behandeling besmet kunnen zijn geraakt door specialist 109. 


(b) Geef de identiteitsnummers van alle specialisten die sinds 3 juli 1989 op directe 
of indirecte wijze via een behandeling besmet kunnen zijn geraakt als gevolg van 
een besmettingshaard in behandelruimte ‘XP4’. 


7 ONDERHOUD 


7.1 TRANSACTIES 


De toestand van een organisatie zal gewoonlijk nogal aan verandering onderhevig zijn: 
medewerkers, klanten en produkten komen en gaan, bestellingen en facturen komen binnen 
en worden verwerkt, en salarissen, voorraden en prijzen stijgen of dalen en passant. De 
administratieve weerslag van zulke veranderingen - in database-kringen wel onderhoud 
genoemd - kunnen we formeel beschrijven met behulp van functies die aan elke mogelijke 
DB-toestand die DB-toestand toevoegen die de nieuwe situatie zou reflecteren. We zullen 
zulke functies transacties noemen. Onze (zeer) algemene definitie luidt als volgt: 


DEFINITIE 7.1: 
Als U een verzameling is, dan: 
fis een transactie op U <= fe U— U. 


VOORBEELD 7.1: 


We lichten het transactiebegrip toe aan de hand van het DB-universum VBU uit Voor- 
beeld 1.3 en het volgende tupel: 


t4 = {(ANR; 3), (NAAM; ‘INKOOP’ ), (MANNR; 7)} 


Uitgaande van VBU zouden we (in onze naiviteit) het toevoegen van het afdelingstupel 
t4 in eerste instantie misschien met behulp van de volgende functie f5 willen 
beschrijven: 
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f5=Av e VBU: {(MEDEW; v(MEDEW)), 
(AFD ;vAFD) U {t4})}. 


De functie f5 blijkt echter geen transactie op VBU te zijn! Weliswaar is f5 een functie 
over VBU maar niet naar VBU: Voor sommige v in VBU is f5(v) namelijk geen ele- 
ment van VBU. Dit doet zich in het bijzonder voor als t4 ¢ v(AFD) terwijl het afde- 
lingsnummer 3 of de afdelingsnaam ‘INKOOP’ wel in v(AFD) voorkomt of het 
medewerkersnummer 7 niet in v(MEDEW) voorkomt. (Zie in dit verband de eisen (2), 
(3) en (5) uit Voorbeeld 1.3.) Als het in de genoemde speciale gevallen wenselijk is om 
de toestand te laten zoals het was, dan zou de beschrijving van de aldus genuanceerde 
toevoegingspoging er als volgt uit kunnen zien: 


f5(v) als f5S(v) e VBU 


fo=Ave veu: y in het andere geval 


De functie f6 is wél een transactie op VBU. 


Als er ook nog dynamische constraints op VBU zouden zijn vastgelegd, dan moest 
bovendien gelden dat (v; f5(v)) een toegestane transitie is. Stel bijvoorbeeld dat er 
alleen in bepaalde situaties nieuwe afdelingen bij mogen komen, bijvoorbeeld alleen 
als het aantal medewerkers een tienvoud of een tienvoud plus één bedraagt. (De 
werkelijkheid gaat wat dat betreft vaak onze fantasie te boven.) De gewenste transi- 
tierelatie is dan 


Ro = {(v; v^) | (v; v^) e VBU x VBU en 
als |v(MEDEW) Imod 10 ¢ {0,1} 
dan id({ ANR }) verbindt v’(AFD) met v(AFD)}. 


(Terzijde merken we op dat dit tevens een voorbeeld van een conditionele verbinding 
is.) 


Als we in het geval van een niet toegestane transitie de toestand weer willen laten zoals 


het was, dan is de bedoelde transactie dus: 


f5(v) als (v ; f5(v)) € Ro 
f7=Av e VBU:4 |, in het andere geval 


We merken op dat (v ; f5(v)) e f5, zodat we f7 met behulp van Definitie 0.16 ook als 
volgt kunnen herschrijven: 
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f7 = {(v; f5(v)) | v e VBU en (v; f5(v)) e Ro} U 
{(v;v) | ve VBU en (v ; f5(v)) € Ro} 
=id(VBU) 8 (Ro A f5). 


O Voorbeeld 7.1. 


In Voorbeeld 7.1 brachten we naar voren dat een transactie ook aan de eventuele dynamische 
constraints moet voldoen en daarom moet “passen” binnen de betreffende transitierelatie Ro. 
We spreken dan wel van een transactie binnen Ro. Formeel: 


DEFINITIE 7.2: 
Als R een relatie is, dan: 
fis een transactie binnen R << fis een functie en f G R. 


Als we Definitie 7.1 en Definitie 7.2 met elkaar vergelijken dan zien we dat elke transactie 
op U tevens een transactie binnen U x U is. Het omgekeerde hoeft niet het geval te zijn 
omdat het domein van een transactie binnen U x U niet noodzakelijk geheel U is (of, anders 
gezegd, omdat de transactie niet noodzakelijk in elke toestand gedefinieerd is). 


In Voorbeeld 7.1 is 
—  f5 geen transactie op VBU, 
—  f6 wel een transactie op VBU maar geen transactie binnen Ro, en 


—  f7 wel een transactie binnen Ro. 


De aanpassingen die we in Voorbeeld 7.1 van f5 maakten om te komen tot een transactie f7 
binnen de transitierelatie Ro zijn van een meer algemeen belang. We voeren daarom het vol- 
gende begrip in: 


DEFINITIE 7.3: 
Als U een verzameling is en Rc U x U en fis een functie, dan: 
Ad(U, R, fF) È id(U) (RN SP). 


We noemen Ad(U, R, f) wel de door U en R bepaalde adaptie van f. We spreken van de 
door U bepaalde adaptie van f als er geen dynamische constraints zijn en we dus in feite te 
maken hebben met de transitierelatie U x U, de meest “liberale” transitierelatie op U. We 
schrijven deze (uitsluitend door de statische constraints bepaalde) adaptie als Adap(U, f): 
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DEFINITIE 7.4: 
Als U een verzameling is en fis een functie, dan: 
Adap(U, f) 2 Ad(U, U xU, f). 


We geven de volgende alternatieve beschrijvingen van de twee zojuist ingevoerde begrip- 
pen: 


f~) alsve dom(f) en f(v)e U 
y in het andere geval 


Adap(U, f)=Av e U d 


fw) alsv e dom(f) en (v; f(v) eR 


Ad(U, R, f)=Ave U ; y in het andere geval 


Als "het andere geval" zich voordoet en de veranderingspoging dus als het ware 
"teruggefloten" wordt, dan spreekt men wel van een rollback van de veranderingspoging. 


Terugblikkend op Voorbeeld 7.1 zien we dat 


Adap(VBU, f5) =f6 en 
Ad(VBU, Ro, f5) = f7. 


STELLING 7.1: 

Als U een verzameling is en R c U x U en f is een functie, dan: 

(a) Adap(U, f) is een transactie op U; 

(b) Ad(U, R, f) is een transactie op U; 

(c) als R reflexief op U is, dan is Ad(U, R, f) een transactie binnen R; 
(d) als feen transactie op U en binnen R is, dan Ad(U, R, f)=f; 

(e) als R reflexief op U is, dan Ad(U, R, Ad(U, R, f)) = Ad(U, R, f). 


Bewijs: 

Omdat f een functie is, is R A f dat volgens Lemma 0.3(a) ook. 

Verder is gegeven dat R CU XU, dus ook Rn fc U x U. 

Uit Definitie 7.3 en Lemma 0.12(a) volgt nu dat Ad(U, R, f) een functie over U is, en wel 
een element van U — U. 

Hiermee is zowel (b) als het meer speciale geval (a) bewezen. 
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Als R reflexief op U is, dan id(U) & R; 
uit Definitie 7.3 volgt dan dat Ad(U, R, f) CR. 
Hiermee is (c) bewezen. 


fis een transactie binnen R, dus f G R. (1) 
fis een transactie op U, dus dom(f ) = U. (2) 
Toepassing van Definitie 7.3, van (1) en van (2) hierboven levert nu achtereenvolgens: 
Ad(U, R, f) =id(U) 0 (RA f) 

=id(U) 6 f 

=f. 


Hiermee is (d) bewezen. 


Onderdeel (e) volgt direct uit de onderdelen (b), (c) en (d). 
mn 


We hebben de voorgaande adaptiebegrippen ingevoerd mede omdat ze goed modelleren hoe 
de interactie tussen een gebruiker en een database management systeem er in het algemeen 
uit zou kunnen zien: bij elke functie f die door een gebruiker als onderhoudsopdracht (dus 
als een speciaal soort "applicatie") wordt opgegeven, zou het DBMS de facto uitvoering kun- 
nen geven aan de adaptie van f bepaald door het DB-universum en de transitierelatie zoals 
die aan het DBMS bekend zijn. Dit betekent dus dat elke statische en dynamische constraint 
die in het DBMS in kwestie specificeerbaar is niet in al die afzonderlijke applicaties hoeft te 
worden “vervlochten” maar centraal in het DBMS kan worden afgevangen. Voor de mate 
waarin we allerlei verfijnde constraints kunnen opgeven aan bestaande DBMS-en bij het 
specificeren van DB-universa en transitierelaties verwijzen we naar Kijkgat 4 in [NGI 88] en 
[IDT 88). 


We willen er heel nadrukkelijk op wijzen dat het achter elkaar uitvoeren van de adapties van 
twee functies f en g zeker niet hetzelfde resultaat hoeft op te leveren als het uitvoeren van de 
adaptie van de samengestelde functie g o f als één “ondeelbaar geheel" (alias één unit of 
work). Anders gezegd, Ad(U, R, g)o Ad(U, R, f) hoeft niet dezelfde functie te zijn als de 
transactie Ad(U, R, go f). Om dit duidelijk te maken werken we beide functies uit en illu- 
streren we een en ander bovendien met een voorbeeld. We zullen hierbij zelfs aannemen dat 
U c dom(f) ^ dom(g) en mg(f) c dom(g), dus dat f en g voor elke DB-toestand van U 
gedefinieerd zijn en dat g bovendien gedefinieerd is voor elk resultaat van f, ook als dat geen 
DB-toestand conform U is. 
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gg) als (w; g(f(v)))ER (A) 


Ad(U, R, g o f)=AveU 4 als (v; g(f(v)))€R (B) 


Ad(U, R, g) ° Ad(U, R, f) 


| AdU, R, 8) FW) als ~; fO) ER 
=Ave UT AdU R, w als: fO)eR 


g(f(v)) als(v;f))e R en(f(v); gf) ER (++) 
ee fv) als@;f@)eER enf); gf) € R (t=) 
5 ‘| a0) als@v;f))¢R enW;g(v))eER (+) 

y als (v;f(v))¢ R en(v;g(v))¢R (~~) 


In principe kunnen alle acht combinaties (A++, A+—, A-+, A-—, B++, B+—, B—+ en B—-) 
zich voordoen. Echter, alleen in de situaties A++ en B—— leveren beide functies met ze- 
kerheid dezelfde resultaten op. 


Ook als er geen dynamische constraints zijn, treden er de nodige verschillen op: 


g(f(v)) als g(f(v))e U (A) 
Adap(U, go f) =AveU +f als g(f(v)) ¢ U (B) 
g(f(v)) als f(v)e U eng(f(v))e U (++) 
fv) als fwje U eng) ¢ U kt) 
Adap(U, g) ° Adap(U, f)= Ave U: 2) als f(v)¢ U eng(v)e U (—+) 
y als f(v)¢ U eng(v)g U (--—) 


Op A+— en B++ na kunnen verder alle zes andere situaties zich voordoen. Ook hier geldt 
weer dat alleen in de situaties A++ en B—— beide functies met zekerheid dezelfde resultaten 
opleveren. 


VOORBEELD 7.2: 
We definiëren twee functies f72 en g72 en schetsen met behulp van Figuur 7.1 


TRANSACTIES 189 


(a) hoe zonder dynamische constraints elk van de situaties A++, A-+, A—-, B+-, 
B-—+ en B—— zich kan voordoen, en 


(b) hoe met dynamische constraints de onder (a) geschetste situaties mogelijk kunnen 
blijven en daarnaast ook de situaties A+— en B+ + kunnen optreden. 


We nemen het DB-universum VBU uit Voorbeeld 1.3 weer als uitgangspunt en bij (b) 
gebruiken we de transitierelatie Ro gedefinieerd in Voorbeeld 7.1. 


De functie f72 beschrijft het toevoegen van een medewerkster Vos bij afdeling 2 met 
een salaris van f3300. Voor het medewerkersnummer wordt hierbij het aantal 
medewerkers plus één gekozen (dit in de stilzwijgende, doch niet noodzakelijk juiste, 
veronderstelling dat de medewerkers opeenvolgend zijn genummerd vanaf 1). 


De functie g72 beschrijft het toevoegen van de afdeling Marketing met medewerker 2 
als manager. Voor het afdelingsnummer wordt hierbij het aantal afdelingen plus één 
gekozen (dit in de veronderstelling dat ook afdelingen opeenvolgend zijn genummerd 
vanaf 1). 


Merk op dat de toe te voegen tupels in feite deels afhankelijk zijn van de toestand 
waaraan ze worden toegevoegd. Die afhankelijkheid wordt beschreven door de hulp- 
functies f71 en g71 die we eerst zullen invoeren. 


Het domein van de functies g71 en g72 willen we zo ruim kiezen dat zowel VBU als 
mg(f72) er binnen vallen, dit om onze aannamen (vlak voor de introductie van de 
gevalsonderscheidingen) gestand te doen. We kiezen daartoe een DB-universum VBU7 
zonder databaseconstraints en zonder tupel- en tabelconstraints voor de tabelindex 
MEDEW. 


De definities luiden nu als volgt: 


VBU7 = II(((MEDEW; P(II(FM))), 
(AFD _ ; WA)}); 


f71=Av e VBU : {(NR; |v(MEDEW)|! +1), (AFDNR; 2), 
(NAAM; ‘VOS’), (SAL; 3300), (GESL; ‘V’)}; 
2g71=Av e VBU7: {(ANR; | v(AFD)I + 1), (MANNR; 2), 
| (NAAM; ‘MARKETING’)}; 
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f12=Ave VBU : v 0 ((MEDEW; (MEDEW) u {f71(v)})}: 
872=Ave VBU7:v0{(AFD ;WAFD) u {g71(v)})}. 


In Figuur 7.1 vermelden we voor elk van de mogelijke situaties aan welke voorwaar- 
den wel ("+") en aan welke niet ("—") voldaan moet zijn door een DB-toestand om deze 
situatie te laten optreden. De tussen haakjes geplaatste plussen en minnen zijn hierbij 
geen extra eisen maar consequenties van de andere eisen. Naast de in Figuur 7.1 
aangegeven eisen stellen we aan elk van die DB-toestanden nog de eis dat daarin nog 
geen afdeling Marketing voorkwam ( ‘MARKETING’ ¢ {t(NAAM) | t e v(AFD)}). 


Elk van de acht situaties werd gekarakteriseerd door het al dan niet toe kunnen passen 
van de functies f72, g72 en g72 o f72. De voorwaarden hiervoor hebben we in Figuur 
7.1 gemakshalve herhaald. 


We maken in Figuur 7.1 gebruik van de volgende afkortingen: 


m, = | v(MEDEW)I + 1 

a, = lv(AFD)I +1 

M, = {t(NR) | te v(MEDEW)} 
A, = {t(ANR) | te v(AFD)} 


g72(f72(v)) e VBU 
f72(v) e VBU 
g72(v)e VBU 


m € M,? 
2e M‚? 
2e M, U {m}? 
ay E€ A? 

Ze A,? 


2e A, U {a,}? (+) + + (+) 


(a) Mogelijke situaties zonder dynamische constraints 
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A++ A-+ A-- B+- B-+ B-- | A+- B++ 
(v; g72(f72(v))) € Ro + + + — — -< + - 
(v; £72(v)) € Ro + — — + — — + + 
(v; g72(v)) € Ro + - + p 
(£72(v); g72(f72(v))) € Ro + - ~ + 
(a) m,e M,? ~ — 
2e M‚? (+) 
2e M‚ U {m,}? + + 
a, E A? ~ — 
Ze A,? + + 
2e A, U {a}? (+) (+) 
©) IxMEDEW)I mod 10? | O  Oof1 Oof1 Oofi Oof! Oof1| 1 9 
=2? JT OG 5 
=2? (3) (+) (+) (>) (-) 


(b) Mogelijke situaties met dynamische constraints 
Figuur 7.1: Voldoende voorwaarden voor karakteristieke voorbeelden 


Voor elk van de acht situaties zullen we nu een DB-toestand in VBU aangeven die aan 
alle voor het optreden van deze situatie noodzakelijke voorwaarden voldoet. We maken 
daartoe gebruik van Figuur 7.2. Deze figuur representeert een AFD-tabel met 3 tupels 
en een MEDEW-tabel met 11 tupels, met dien verstande dat de AFD-tabel nog de 
"parameters" a en B en de MEDEW-tabel nog de "parameters" y en 5 bevat. 


PRODUCTIE 
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(a) Een sjabloon voor enige AFD-tabellen 
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(b) Een sjabloon voor enige MEDE W-tabellen 


Figuur 7.2: Een sjabloon voor enige DB-toestanden in VBU 


Met deze "tabel-sjablonen" als basis beschrijven we in Figuur 7.3 een achttal DB- 
toestanden in VBU door in de eerste plaats de aantallen AFD-tupels en MEDEW- 
tupels geschikt te kiezen en vervolgens de waarden voor de parameters a, B, y en ô 
(voor zover van toepassing) geschikt te kiezen. In die situaties waarin we voor een 
DB-toestand minder dan drie afdelingen of minder dan elf medewerkers nodig hebben 
laten we "de tupels onderin" weg (zie de open ruimtes tussen de tupels in Figuur 7.2). 
Dus, om de situaties B+—, B—+, B—— en A+- te verkrijgen zullen we telkens alle drie 
AFD-tupels en alle elf MEDEW-tupels kiezen, voor de situatie A++ laten we 
medewerker 15 weg, voor B++ laten we de twee medewerkers 14 en 15 weg, voor 


A-—+ volstaan we met afdeling 1 (en elf medewerkers) en voor A—— nemen we alleen 
afdeling 1 en medewerker 1. 
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g72 o f72 toepasbaar? + + + — = itp 4 k 
f72 toepasbaar? + — — + — — + + 
g72 toepasbaar? + + — — + ~ > F 
| v(AFD)| 3 1 1 3 3 3 3 3 
|I y(MEDEW)| 10 11 1 11 11 11 11 9 
AFD: a 2 nvt nvt 2 2 3 2 2 

B 3 nvt nvt 4 3 4 3 3 
MEDEW: y 2 2 3 3 2 S 2 2 

5 13 13 13 13 12 12 13 13 


Figuur 7.3: Acht karakteristieke DB-toestanden in VBU, gebaseerd op Figuur 7.2 


O Voorbeeld 7.2. 


OPGAVEN 


7.1. In deze opgave refereren we aan de in Voorbeeld 7.1 ingevoerde functies f5 en f6. We 
definiëren f8 = Ad(VBU, VBR, f5), waarbij VBR de in Voorbeeld 5.1 gedefinieerde 
transitierelatie is. 

Bewijs dat f8 = f6. 


7.2. Als U een verzameling is en R c U XU en f is een functie, dan is Ad(U, R, f) een 
transactie binnen R U id(U). Bewijs dit. 


7.3. Geef voor elk van de 12 "minnen" in Figuur 7.3 een reden aan. 


m 
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7.2 ENIGE GANGBARE KLASSEN VAN TRANSACTIES 


Om een indruk te geven van de gangbare transactiemogelijkheden van bestaande DBMS-en, 
en van de SQL2-standaard bijvoorbeeld (zie [SQL 89]), zullen we enige speciale klassen van 
transacties invoeren die tezamen het grootste deel van die bestaande mogelijkheden over- 
dekken en in sommige opzichten zelfs aanzienlijk verder gaan. Het leeuwedeel van de 
huidige transactiemogelijkheden kenmerkt zich daardoor dat de veranderingen zich plegen te 
beperken tot slechts één enkele tabelindex tegelijk. Iets nauwkeuriger gezegd: De ter 
beschikking gestelde transacties zijn allemaal van de vorm Ad(U, R, f) waarbij f een functie 
over het DB-universum U is zodanig dat voor één bepaalde tabelindex Ey van U het beeld 
f(v) voor elke v e U een functie over de tabelindexenverzameling He(U) is met de eigen- 
schap dat f(v)+ {Eo} =v+ {Eo}. Dit betekent dus dat we in deze gevallen alleen de veran- 
deringen voor de Eg-tabel hoeven te specificeren. We voeren daarom het volgende hulp- 
begrip in: 


DEFINITIE 7.5: 
Als U een DB-universum isen R c U x U en Ee He(U) ent is een functie over U, dan: 
Main(U, R, E, ©) 2 Ad(U, R, Ave U : v 0 ((E; +v))}). 


Dus Main(U, R, E, t) is de functie over U die aan elke DB-toestand v van U de toestand toe- 
voegt waarin de E-tabel de waarde t(v) heeft en de andere tabelindexen nog hun "oude" 
waarde hebben, althans als dit een toegestane transitie vormt; als deze transitie niet is toege- 
staan dan wordt aan v gewoon v zelf toegevoegd. We noemen Main(U, R, E, t) wel de 
maintenance van E volgens t (binnen de grenzen van R op U). Ter illustratie merken we op 
dat de functie f7 uit Voorbeeld 7.1 te schrijven is als Main(VBU, Ro, AFD, 
Ave VBU: v(AFD) U {t4}). 


Met behulp van de speciale klasse van "ééntabel-transacties" die we zojuist in Definitie 7.5 
hebben ingevoerd kunnen we nu op eenvoudige wijze de gangbare SQL-achtige transacties 
definiëren. 


We beginnen met een elementaire “insert-operatie”, het toevoegen van één gegeven tupel t 
aan de E-tabel (mits daarbij aan alle statische en dynamische constraints is voldaan): 
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DEFINITIE 7.6: 
Als U een DB-universum isen R c U x U en E e He(U) ent is een functie, dan: 
Inst(U, R, E, t) È Main(U, R, E, Av e U : v(E) U {t}). 


Ter illustratie merken we op dat de functie f7 uit Voorbeeld 7.1 van deze vorm is en te 
schrijven is als Inst(VBU, Ro, AFD, t4). Hiermee is dus op compacte én correcte wijze het 
(eventueel) toevoegen van het tupel t4 aan de AFD-tabel binnen de grenzen van de transi- 
tierelatie Ro op het DB-universum VBU gespecificeerd. 


We vervolgen met de tweede gangbare soort insert-operatie, het toevoegen van een query- 
resultaat aan de E-tabel (mits daarbij weer aan alle statische en dynamische constraints is 
voldaan): 


DEFINITIE 7.7: 

Als U een DB-universum is en R c U XU en Ee He(U) en q is een verzamelingsfunctie 
over U, dan: 

Insq(U, R, E, q) = Main(U, R, E, Av € U : v(E) U q(w)). 


Het is eenvoudig in te zien dat Definitie 7.6 een speciaal geval is van Definitie 7.7: 
Inst(U, R, E, t)= Insq(U, R, E, Av e U : {t}). 


De transactie Insq(U, R, E, q) specificeert dus de poging tot het "in één klap" toevoegen van 
de verzameling q(v) aan de E-tabel en niet het één voor één pogen toe te voegen van de 
afzonderlijke elementen van de verzameling q (v); het is dus een "alles of niets"-operatie. 


VOORBEELD 7.3: 
De poging tot het in één keer toevoegen van de tabel T1 uit Voorbeeld 1.1 (bevattende 
drie "kandidaat-medewerkers") aan de MEDEW-tabel binnen de in Voorbeeld 7.1 
ingevoerde transitierelatie Ro op het DB-universum VBU kunnen we specificeren met 
gebruikmaking van de volgende (constante) functie: 


q70 =A\v e VBU: T1 


De bedoelde transactie is nu Insq(VBU, Ro, MEDEW, q70). In geval van een DB- 
toestand v e VBU waarbij bijvoorbeeld één van de medewerkersnummers uit T1 al 
voorkomt in v(MEDEW) of één van de afdelingsnummers uit T1 niet voorkomt in 
v(AFD) zal dus geen enkel element van T1 worden toegevoegd. 


Bij het één voor één pogen toe te voegen van de afzonderlijke elementen van T1 kan 
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het zijn dat sommige elementen wel en sommige elementen niet toegevoegd worden, 
bijvoorbeeld als afdeling 1 wel in v(AFD) voorkomt maar afdeling 2 niet. Als we de 
elementen van T1 even t7, t8 en t9 noemen, dan kunnen we de "batch" van pogingen 
om achtereenvolgens t7, t8 en t9 toe te voegen specificeren als 


Inst(VBU, Ro, MEDEW, t9) o Inst(VBU, Ro, MEDEW, t8) o Inst(VBU, Ro, MEDEW, t7) 


O Voorbeeld 7.3. 


De volgende operatie betreft het verwijderen van een query-resultaat uit de E-tabel (mits ook 
daarbij weer aan alle constraints is voldaan). Zo’n operatie wordt wel een "delete-operatie" 
genoemd. 


DEFINITIE 7.8: 


Als U een DB-universum is en RC U XU en Ee He(U) en q is een verzamelingsfunctie 
over U, dan: 
Del(U, R, E, q) = Main(U, R, E, àv € U : v(E)-q(v)). 


Het "leegmaken" van de E-tabel is hiervan een belangrijk speciaal geval: neem 
g=AveU: v(E). 


VOORBEELD 7.4: 
We geven enkele voorbeelden van delete-operaties aan de hand van het DB-universum 
VBU en de transitierelatie VBR uit Voorbeeld 5.1. We geven eerst de informele 


omschrijvingen, vervolgens de onderliggende queries en tenslotte de bedoelde delete- 
operaties. 


De informele omschrijvingen van de verwijder-opdrachten luiden: 


(1) Verwijder de medewerker met medewerkersnummer 3. 

(2) Verwijder alle medewerkers van afdeling 3. 

(3) Verwijder alle medewerkers van afdeling 3 die geen manager van een afdeling 
zijn. 


(4) Verwijder alle afdelingen zonder medewerkers. 


De queries die aan deze delete-opdrachten ten grondslag liggen zullen we gemakshalve 
q71, q72, q73 en q74 noemen: 
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(1) q71=Ave VBU: (te v(MEDEW) | t(NR)=3}. 
(2) q/2=Av e VBU: {t e v(MEDEW) | t(AFDNR) = 3}. 
(3) q/3=Ave VBU: (te v(MEDEW) | t(AFDNR) = 3 en 


t(NR) ¢ {a(MANNR) | a € v(AFD)}}. 


(4) q74=Ave VBU: (a € v(AFD) | a(ANR) ¢ {t(AFDNR) | t € v(MEDEW)}}. 


De gevraagde delete-operaties zijn nu: 


(1) Del(VBU, VBR, MEDEW, q71). 
(2) Del(VBU, VBR, MEDEW, q72). 
(3) Del(VBU, VBR, MEDEW, q73). 
(4) Del(VBU, VBR, AFD „q74). 


Gezien de definitie van VBR worden delete-pogingen op de MEDEW-tabel niet 
beïnvloed door dynamische constraints. We gaan elk van de vier delete-operaties nog 
even aan een nadere beschouwing onderwerpen. 


Ad(1): 


Ad(2): 


Ad(3): 


Ad(4): 


Hier wordt maximaal één tupel verwijderd. Er wordt uiteraard niets 
verwijderd als 3 niet als medewerkersnummer voorkomt. Doch ook als 3 wel 
als medewerkersnummer in de MEDEW-tabel voorkomt kan het zijn dat er, 
wegens een statische constraint, niets wordt verwijderd, namelijk in het geval 
dat 3 ook als managersnummer in de AFD-tabel voorkomt. 


Hier worden nul, één of meer MEDEW-tupels "tegelijk" verwijderd. Als 
echter ten minste één medewerker van afdeling 3 ook een manager is (al dan 
niet van afdeling 3 zelf), dan wordt geen enkel MEDEW-tupel verwijderd. 


Deze opdracht is een nuancering van de vorige. Hier worden alle in aanmer- 
king komende MEDEW-tupels verwijderd, niet gehinderd door enige statische 
of dynamische constraint. 


Uit de dynamische constraint DCI in de definitie van de transitierelatie VBR 
blijkt dat er geen ANR-waarden mogen verdwijnen en, daar {ANR} een sleu- 
tel van AFD in VBU is, derhalve überhaupt geen AFD-tupels! Dit betekent 
dus dat elke verwijderingspoging betreffende de AFD-tabel gedoemd is te 
mislukken. Uit deze “intrinsieke rollback" concluderen we dat 
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Del(VBU, VBR, AFD, q74) = id(VBU). 
O Voorbeeld 7.4. 


De laatste (en meest subtiele) klasse van gangbare transacties die we behandelen is de klasse 
van de zogeheten "update-operaties". Het gaat hierbij om wijzigingen van (delen van) be- 
staande tupels. Wat we hierbij nodig hebben is een functie q over het betreffende DB- 
universum U waarbij q(v) voor elke v e U aangeeft welke gedeelten van welke E-tupels op 
welke wijze veranderd dienen te worden. Meer bepaald is het onze bedoeling dat g(v) een 
functie is over een deelverzameling van v(E), namelijk de verzameling van de te wijzigen 
E-tupels, en wel zodanig dat q(v) (t) voor elke t e dom(q(v)) het gewijzigde tupelfragment 
van t weergeeft. Dit leidt ons tot de volgende algemene definitie: 


DEFINITIE 7.9: 
Als U een DB-universum isen Rc U x U en E e He(U) eng is een functie over U en 
Vve U : q(w) is een functiewaardige functie met dom(q(v)) c v(E), dan: 
Upd(U, R, E, q) = Main(U, R, E, Av € U : (v(E) —dom(q(w))) U 
{t 0 q(w) (t) | t e dom(q(w))}). 


Met andere woorden, elk element t van dom(q(v)) wordt vervangen door t 0 q (v) (t). Ook 
hier geldt weer het voorbehoud dat na de gewenste wijzigingen aan alle constraints moet zijn 
voldaan; zo niet, dan blijft de toestand weer zoals het was. 


VOORBEELD 7.5: 
We geven enkele voorbeelden van update-operaties aan de hand het DB-universum 
UZKH uit Hoofdstuk 4 en de transitierelatie RZKH uit $5.2. Evenals in Voorbeeld 7.4 


geven we weer eerst de informele omschrijvingen, dan de onderliggende "update- 
queries” en tenslotte de bedoelde update-operaties. 


De informele omschrijvingen van de wijzigingsopdrachten luiden: 


(1) Zet voor ieder werknemer het aantal ziektedagen weer op nul. 


(2) Wijzig voor de plaats Lutjebroek het aantal tandartsen in 5, verhoog het aantal 
huisartsen met 2 en verdubbel het aantal apothekers. 


(3) Wijzig van huisarts 99 het patiëntenaantal (per 1 januari j.l.) in 747, pas de 
“patiëntentoename vorig jaar" dienovereenkomstig aan (nu we een jaar verder 
zijn) en verhoog de verwachte toe- of afname met 10% (eventueel naar beneden 
afgerond). 
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(4) 


(5) 


Voeg voor de patiënt met nummer 123453 een dochtertje Cherelien toe, geboren 
op 26 februari 1988. 


Verminder voor elk medicijn de voorraad met de totaal op 3 mei 1989 verstrekte 
hoeveelheid. 


Aan deze wijzigingsopdrachten liggen de volgende queries over UZKH ten grondslag: 


(1) 
(2) 


(3) 


(4) 


(5) 


q75 =v e UZKH: At e v(WN): {(AZD; 0)}. 
q76=Av e UZKH: Ate v(PLR) en t(WPL) = ‘Lutjebroek’: 

{(ATA;5), (AHA; t(AHA)+2), (AAP; 2* t(AAP))}. 
q77=Av e UZKH: Ate v(HA) en t(NRHA) = 99: 

{(PAT ; 747), (TOEN ; 747 —t(PAT)), 

(VWTN ; (VWTN) + £(VWTN) div 10)}. 

q78 =Av e UZKH: At e v(PAT) en (PNR) = 123453: 

{(KNDG; (KNDG) U {t78})}, 
waarbij t78 = {(VNM; ‘Cherelien’), (GBD; 19880226), (GESL, ‘V’)}. 
q79=Av e UZKH: At e (MED): 
{(VRD; (VRD) — (Xx e v(MVS) en x(MCD) = t(MCD) en x(DAT) = 890503: 

x(DUUR) * x(FREQ) * x(AEK)))}. 


De gevraagde update-operaties zijn nu: 


(1) 
(2) 
(3) 
(4) 
(S) 


Upd(UZKH, RZKH, WN , q75). 
Upd(UZKH, RZKH, PLR , q76). 
Upd(UZKH, RZKH, HA , q77). 
Upd(UZKH, RZKH, PAT , q78). 
Upd(UZKH, RZKH, MED, q79). 


We geven bij elk van de vijf wijzigingsopdrachten nog enig commentaar. In het 
bijzonder gaan we "met de hand" na welke dynamische en statische constraints tot een 
rollback zouden kunnen leiden. (Het is echter de taak van het DBMS om deze con- 
straints “automatisch” te controleren.) 


200 


Ad(1): 


Ad(2): 


ONDERHOUD 


Ter illustratie van Definitie 7.9 (en enkele andere in dit hoofdstuk ingevoerde 
begrippen) willen we voor dit eerste voorbeeld de gegeven oplossing nog even 
expliciet "terugrekenen". We maken daarbij gebruik van de definities 7.5 en 
7.3 en de eigenschappen van q75 dat dom(q75(v)) = v(WN) en q75(v) (t) = 
((AZD; 0)}. 


Upd(UZKH, RZKH, WN, q75) 
= Main(UZKH, RZKH, WN, Av e UZKH: (v(WN) — dom (q75(v))) U 
{t 0 q75(v) (t) | t e dom(q75(v))}) 
= Main(UZKH, RZKH, WN, Av e UZKH: {t 6 {(AZD; 0)} | t e v(WN)}) 
= Ad(UZKH, RZKH, Av e UZKH: v 0 {(WN;; {t 0 {(AZD; 0)} | te v(WN)})}) 
= Id(UZKH) 6 (RZKH NA Ave UZKH: v 6 {(WN; {t 6 {(AZD; 0)} | te v(WN) 


Uit de definitie van UZKH in 84.2 blijkt vrij eenvoudig dat | 
v 0 ((WN; {t 0 ((AZD; 0)} | te v(WN)})} voor elke v e UZKH weer een 
element van UZKH is. Immers, alleen de AZD-waarden van de WN-tabel 
worden maar aangepast, en de enige constraint die er ten aanzien van deze 
AZD-waarden geldt is de eis dat ze in de verzameling [0 … 290] moeten lig- 
gen. Hieraan is in de nieuwe situatie duidelijk voldaan. Verder voldoet voor 
elke ve UZKH het paar (v; v 6 {(WN; {t 6 {(AZD; 0)} | te v(WN)})}) 
aan de dynamische constraint C12 in §5.2 en (op triviale wijze) ook aan alle 
andere constraints in de definitie van de transitierelatie RZKH. We kunnen 
daarom de hierboven gegeven vereenvoudiging van Upd(UZKH, RZKH, WN, _ 
q75) nog één stap verder doorvoeren: 


Upd(UZKH, RZKH, WN, q75) 
=Àv e UZKH: v 6 {(WN; {t 6 ((AZD; 0)} | te v(WN)})}. 


Wanneer de plaats Lutjebroek niet voorkomt in v(PLR), dan zijn er geen 
wijzigbare tupels. De toestand blijft dan ook gewoon ongewijzigd (zonder dat 
er van een rollback sprake is). We bekijken nu wat er zou gebeuren wanneer 
de plaats Lutjebroek wel voorkomt in v(PLR). Er zijn in §5.2 geen dyna- 
mische constraints die betrekking hebben op de PLR-tabel. Bekijken we de 
definitie van UZKH in §4.2, dan lezen we daar uit af dat de statische 
(tupel)constraint R44 de enige constraint is die roet in het eten kan gooien. 
Wanneer namelijk de plaats Lutjebroek wel in v(PLR) voorkomt en door de 
verhoging van het aantal huisartsen met twee dat aantal opeens vier of meer 
wordt - en dus twee of drie was - én bovendien de dienstdoende huisarts Lutje- 
broek niet als praktijkplaats heeft, dan gaat de wijziging niet door. (Er is dan 
wel sprake van een rollback.) 
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Ad(3): 


Ad(4): 


Ad(5): 


Wanneer er geen tupel met huisartsnummer 99 voorkomt in v(HA), dan wor- 
den er geen tupels gewijzigd. We bekijken nu het effect wanneer er wel zo’n 
tupel in v(HA) voorkomt. De enige dynamische constraint in de definitie van 
de transitierelatie RZKH die betrekking heeft op de HA-tabel is C14. Het 
gewijzigde tupel t’ in de nieuw voorgestelde toestand voldoet inderdaad aan 
de aldaar gestelde eis dat (TOEN) = t’(PAT) — (PAT), want t’(PAT) = 747. 
De enige statische constraints in de definitie van het DB-universum UZKH die 
betrekking hebben op de te wijzigen attributen in de HA-tabel zijn de tupel- 
constraints R40 en R41. Voor het gewijzigde tupel t geldt dat t’ (PAT) 
— (TOEN) = 747 — (747 — t(PAT)) = (PAT). Aangezien het "oude" tupel t 
afkomstig is van een element v van UZKH zelf, voldoet t dus aan de in de 
objectkarakterisering FHA gestelde eis dat t(PAT) e IN. Dus t(PAT) 2 0. We 
concluderen hieruit dat de tupelconstraint R40 bij deze transactie dus niet kan 
leiden tot een rollback. Wat de tupelconstraint R41 betreft, wordt voor het 
gewijzigde tupel tf’ geëist dat t(PAT)+4(VWTN)20, ofwel dat 
747 + t(VWTN) + (¢(VWTN) div 10) 2 0 voor het oude tupel t. Dit laatste 
komt neer op de eis dat ((VWTN) > —680. Wanneer dus de "oude verwach- 
ting" een daling van 680 of meer patiënten was, dan kan de voorgestelde 
wijziging niet gehonoreerd worden. 


Wanneer er geen tupel met patiëntnummer 123453 voorkomt in v(PAT), dan 
vindt er gewoon geen wijziging plaats. Wanneer zo’n tupel wel voorkomt, dan 
is de enige constraint die tot een rollback kan leiden de statische 
(attribuut)constraint R02. Deze eis houdt in dit geval in dat onder de reeds 
geregistreerde kinderen van patiént 123453 de naam Cherelien nog niet voor- 
komt (tenzij met geboortedatum 19880226 en geslacht ‘V’). 


Hier komen alle MED-tupels voor wijziging in aanmerking. De enige con- 
straint die bij deze transactie tot een rollback kan leiden is de statische con- 
straint voor het attribuut VRD van de MED-tabel dat de voorraad groter dan of 
gelijk aan 0 moet zijn. Wanneer door de voorgestelde wijzigingen één of meer 
van de voorraden negatief zou worden, dan wordt van geen enkel medicijn de 
voorraad gewijzigd. (Een en ander wijst kennelijk op een administratieve fout 
die tot inaccurate gegevens heeft geleid, of dreigt te leiden, waardoor het 
blijkbaar veiliger is bevonden om dan nog maar helemaal geen veranderingen 
door te voeren.) 


O Voorbeeld 7.5. 
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OPGAVEN 


7.4. In deze opgave komen we terug op Upd(UZKH, RZKH, WN, q75), de eerste van de in 
Voorbeeld 7.5 behandelde transacties. We zullen deze transactie even ® noemen. 
Bewijs dat ® idempotent is onder functiecompositie, dat wil zeggen dat Do D= ®. 


7.5. Ga na welke statische en dynamische constraints tot een rollback van de transactie 
Inst(UZKH, RZKH, PAT, t) kunnen leiden als gegeven is dat t e II(FPAT). Hierbij is 
FPAT de in $4.2 gedefinieerde objectkarakterisering voor de tabelindex PAT. 


7.6. Geef de volgende, informeel omschreven opdrachten over het DB-universum VBU 
voorzien van de transitierelatie VBR uit Voorbeeld 5.1 formeel weer. 


(a) Geef alle medewerkers van de afdelingen 3 en 4 een salarisverhoging van 5% 
(waar nodig naar beneden afgerond). 


(b) Geef elke manager een salarisverhoging van f 100,-. 


(c) Geef elke manager een salarisverhoging van f 100,- en bovendien alle medewer- 
kers van de afdelingen 3 en 4 een salarisverhoging van 5%. (Voor managers die 
aan afdeling 3 of 4 verbonden zijn, geldt deze 5% niet over deze extra f 100,-.) 


(d) Geef elke manager een salarisverhoging van f 100,- voor elke afdeling waarvan 
hij of zij manager is. 


7.1. Deze opgave heeft betrekking op Voorbeeld 2.13. Laat t4 e TI(F5) en tg e II(FS) met 
ta + tpg en tLA(PROV) = ta(PROV). 


De plaats gerepresenteerd door t4 wordt geannexeerd door de plaats gerepresenteerd 
door tg. Dit betekent dat t, de naam van tg erft, de burgemeester van t4 gewoon burger 
van tg wordt en de inwoners van t4 voortaan inwoners van tg zijn. Geboorteplaatsen 
worden niet gewijzigd. 


Geef een formele definitie van de transactie Annex(t,, tg) e U1 — U1 die de admini- 
stratieve verwerking van de geschetste gemeentelijke herindeling representeert. 


1.8. Geef een formele definitie van de transactie Delpb(to) e UZKH —® UZKH, waarbij 
to € TI(FPB) | (PNR, BCD, VNR}, die aan elke DB-toestand v € UZKH toevoegt de 
toestand die uit v ontstaat door het (eventuele) patiëntbehandelingstupel met de door to 
beschreven steutelwaarde weg te laten en bovendien de daarvoor in aanmerking 
komende volgnummers met 1 te verlagen. (Er zijn geen dynamische constraints.) 
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a 


7.10. 


Tk 


Geef een formele definitie van de transactie Updsous(xg) e UZKH — UZKH binnen 
RZKH, waarbij x9 € Vng(4), die aan elke DB-toestand v e UZKH toevoegt de toe- 
stand die uit v ontstaat wanneer een werknemer met identiteitsnummer x9 de taken van 
zijn souschef, dat wil zeggen inclusief diens groepsleiderschap, overneemt. 

(De souschef wordt een gewoon lid van zijn groep en als werknemer xo reeds 
groepsleider was dan worden die twee groepen als samengevoegd beschouwd.) 


Deze opgave heeft betrekking op Voorbeeld 3.6. 

Geef een formele definitie van de transactie Make(p)e UBP —P> UBP, waarbij 
p € [40000 … 99999), die aan elke DB-toestand v e UBP toevoegt de toestand die uit v 
is ontstaan wanneer één exemplaar van het produkt met produktnummer p rechtstreeks 
is geproduceerd vanuit z’n directe onderdelen, mits p als produktnummer bekend is en 
alle directe onderdelen in voldoende aantallen in voorraad zijn; is dat niet het geval dan 
blijft de toestand dezelfde. (Er zijn geen dynamische constraints.) 


Geef een formele definitie van de transactie Insmvs(xo) e€ UZKH —> UZKH, waarbij 
xo € II(FMVS + {VNR}), die aan elke v e UZKH toevoegt de toestand die uit v 
ontstaat door toevoeging van het door x9 bijna geheel beschreven medicijnverstrek- 
kingstupel, waarbij 


— het volgnummer het eerste "vrije" positieve getal voor die patiënt is, 
— OOk het aantal eenheden in voorraad is aangepast, en 


— er geen dynamische constraints zijn, 


mits een en ander zou resulteren in een toestand die tot UZKH behoort; is dit niet het 
geval dan blijft de toestand zoals het was. 


8 DATA DICTIONARIES 


De data dictionary, ook wel systeemcatalogus genoemd, vormt een centraal onderdeel van 
een database management systeem. Het bevat meta-gegevens, dat wil zeggen gegevens over 
de gegevens in de database. De data dictionary kan gegevens bevatten zoals 


(a) 


(b) 


(c) 
(d) 


(e) 


(f) 
(g) 
(h) 
(i) 
G) 


(k) 


tabelnamen, attributen, de voor die attributen toegestane waarden, sleutels, 
verbindingseisen en andere constraints, kortom een beschrijving van het betreffende 
DB-universum, 


gegevens over de huidige DB-toestand, zoals bijvoorbeeld het aantal elementen per 
tabel of het aantal verschillende waarden per attribuut van een tabel, 


namen en definities van views, menus, procedures, schermen, schermvelden, etcetera, 


(statistische) gegevens over het database-gebruik tot nu toe, bijvoorbeeld uitgesplitst 
per afdeling en/of per periode, 


gegevens over de fysieke structuur van de database (unique en non-unique indexes, 
clusters, disk devices, gereserveerde ruimte, bezette pages per tabel), 


autorisatiegegevens (wie mag wat zien en wie mag wat doen?), 
“creators” en eigenaren van tabellen, views, programma’s, etcetera, 
toegestane gebruikers en gebruikersgroepen, hun wachtwoorden en privileges, 


gegevens over lopende processen, zoals bijvoorbeeld de door het proces "gelockte" 
gegevens, het aantal disk reads en disk writes en de aanvragende gebruiker, 


gegevens over de distributie van de feitelijke gegevens over de diverse machines (in 
geval van een gedistribueerde database), en 


eventueel ook gegevens over de data dictionary zelf. 


Voor meer informatie over bovengenoemde aspecten verwijzen we de lezer naar de litera- 
tuur, bijvoorbeeld naar [Da 86), [IDT 88], [NGI 88], [NGI 87], [We 86], [Ma 84], [ALM 82], 
[LP 82], [CD 81], [SM 80], [Uh 73] en naar de daarin genoemde referenties. 
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In dit hoofdstuk zullen we aan de hand van het gegevensdefinitie-gedeelte van een data dic- 
tionary, dat wil zeggen aan de hand van de onder (a) genoemde meta-gegevens, laten zien 
hoe een data dictionary niet alleen formeel kan worden weergegeven, maar ook hoe de 
semantiek ervan kan worden geformaliseerd. We besluiten deze inleiding met de opmerking 
dat dit hoofdstuk een bewerking is van [Br 88]. 


8.1 HET DATA-DEFINITIEGEDEELTE VAN EEN DATA DICTIONARY 


Het data-definitiegedeelte van een data-dictionarysysteem bepaalt welke DB-universa met 
behulp van dit data-dictionarysysteem kunnen worden beschreven. Elke beschrijving die 
specificeerbaar is middels het betreffende data-dictionarysysteem bepaalt op eenduidige 
wijze een DB-universum, een wijze die specifiek is voor het systeem in kwestie. Het data- 
definitiegedeelte van een data-dictionarysysteem kunnen we daarom formeel representeren 
door een functie die aan elke (binnen dit systeem specificeerbare) beschrijving het bedoelde 
DB-universum toevoegt. We zullen zo’n functie een DD-functie noemen: 


DEFINITIE 8.1: 
I is een DD-functie po I is een functie en 
Vd e dom(/) : /(d) is een DB-universum. 


Als J een DD-functie is, dan noemen we dom(/) wel het DD-universum van I; als U e mg(J), 
dan zeggen we wel dat U kan worden beschreven met behulp van I. Als bovendien 
(d; U) € I, dan noemen we d wel een beschrijving van U volgens I en omgekeerd U wel het 
door d volgens I beschreven DB-universum of ook wel de semantiek (of interpretatie) van d 
volgens I. 


VOORBEELD 8.1: 
We beginnen met een relatief eenvoudig voorbeeld van een DD-functie. We zullen 
deze functie I1 noemen. Elk element van dom(I1) is een DB-skelet waarin elke tabelin- 
dex en elk attribuut een string is, en wel van ten hoogste 16 tekens. Kortom, dom(I1) = 
(Chs(16) —& P(Chs(16))). De DD-functie I1 beeldt elke g e dom(I1) af op het een- 
duidig bepaalde DB-universum over g waarin elk attribuut een willekeurige string van 
ten hoogste 16 tekens als waarde kan hebben en waarin verder geen andere voorwaar- 
den gelden. Met andere woorden, voor elke tabelindex Æ e dom(g) kan een "E-tabel" 
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een willekeurige deelverzameling van g (E) —> Chs(16) zijn. Kortom, het door g vol- 
gens I1 beschreven DB-universum is 


II (AE e dom(g) : P(g(E) — Chs(16))) 
De bedoelde DD-functie I1 kunnen we daarom als volgt definiéren: 
I1=Ag e (Chs(16) —& P(Chs(16))) : 
II QE e dom(g) : P(g (E) —& Chs(16))). 


Het blijkt dat er in mg(11) per DB-skelet g e Chs(16) — P(Chs(16)) precies één DB- 
universum over g voorkomt. Dit DB-universum kan ook maar op één manier worden 
beschreven met behulp van I1 daar I1 een injectieve functie blijkt te zijn. 


Ter illustratie zullen we I1 toepassen op het volgende kleine DB-skelet: 


g3 = {(‘EMP’; { ‘ENAME’ , ‘ADDRESS’, ‘CITY’, ‘DCODE’ }), 
(‘DEP’; (‘DNAME’, ‘DCODE’, ‘MANNAMP’ })} 


employees 
departments 


Het is eenvoudig in te zien dat g3 een element van Chs(16) — P(Chs(16)) is. Dus g3 
e dom(I1). We gaan nu uitrekenen welk DB-universum volgens I1 door g3 wordt 
beschreven. We berekenen het DB-universum I1(g3) door achtereenvolgens de 
definitie van I1, de definitie van g3 en Lemma 0.15(a) toe te passen: 


I1(g3) 
=II(QE e dom(g3): P(g3(E) —> Chs(16))) 
= II({( EMP’; P(g3( ‘EMP’ ) — Chs(16))), 
(“DEP’; P(g3( ‘DEP’ ) —> Chs(16)))}) 
= TI({(‘EMP’; P(I({(‘ENAME’ ; Chs(16)), 
(‘ADDRESS’ ; Chs(16)), 
Cary ; Chs(16)), 
(‘DCODE’ __ ; Chs(16))}))), 
( ‘DEP’; P(IIC((SDNAME’ __ ; Chs(16)), 
(‘DCODE’ ; Chs(16)), 
(‘MANNAME’; Chs(16))})))}). 
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Waar we ons in de voorgaande hoofdstukken niet of nauwelijks hoefden uit te laten 
over de aard van tabelindexen en attributen, zullen we in de voorbeelden in dit 
hoofdstuk voor tabelindexen en attributen telkens expliciet kiezen voor strings. Dien- 
tengevolge gaan we daarom nu ook zorgvuldiger met quotes om. 


O Voorbeeld 8.1. 


We noemen een DD-functie 7 ten minste even expressief als een DD-functie J’ als met Z alle 
DB-universa kunnen worden beschreven die ook met J’ kunnen worden beschreven. 

We noemen 7 en I’ DD-equivalent als ze precies dezelfde verzameling DB-universa kunnen 
beschrijven. Formeel: 


DEFINITIE 8.2: 
Als J en I’ DD-functies zijn, dan: 


(a) J is ten minste even expressief als 7’ <> mg(/’) c mg(/); 


(b) Zis DD-equivalent met 7’ <> mg(/’) = mg(/). 


Twee DD-equivalente DD-functies kunnen niet alleen verschillen in hun domein, dus in hun 
verzameling beschrijvingen, maar ook in de manier waarop hun eventuele gemeenschap- 
pelijke beschrijvingen worden geïnterpreteerd: als Z en J’ twee DD-equivalente DD-functies 
zijn en d e dom(/) ^ dom(/’), dan hoeft /(d) niet gelijk te zijn aan /’(d). Omgekeerd hoeven 
twee DD-functies met hetzelfde domein niet DD-equivalent te zijn, zie de voorbeelden 8.4 
en 8.5. 


We merken op dat de range van een DD-functie / een verzameling DB-universa is en daarom 
niet de klasse van alle DB-universa omvat. (Voor een uitgebreide behandeling van dit ver- 
zamelingstheoretische onderscheid verwijzen we de lezer naar bijvoorbeeld [DDS 75].) Er 
bestaat daarom voor elke DD-functie 7 wel een DD-functie 7’ die expressiever is, dat wil zeg- 
gen waarmee "meer" DB-universa kunnen worden beschreven dan met J. We komen dan ook 
tot de (commercieel) belangwekkende conclusie dat er dus niet zoiets bestaat als een 
“universele, alomvattende" DD-functie waarmee de klasse van alle DB-universa zou kunnen 
worden beschreven. 


Het volgende lemma suggereert een eenvoudige manier om de expressiviteit van twee DD- 
functies met elkaar te vergelijken. 


LEMMA 8.1: 
Als J en 7’ DD-functies zijn en A is een functie zodanig dat J’ =] o h, 
dan is / ten minste even expressief als 7’. 


208 DATA DICTIONARIES 


Dit lemma volgt direct uit Definitie 8.2(a) en Lemma 0.9(c). De functie h "converteert" een 
beschrijving volgens 7’ naar een beschrijving volgens /. We noemen A in dit verband dan ook 
wel een DD-conversiefunctie of, als h relatief “eenvoudig” is, een DD-migratiefunctie. 


VOORBEELD 8.2: 

We zullen een DD-functie I2 definiëren die DD-equivalent is met de DD-functie I1 uit 
Voorbeeld 8.1. In essentie is I2 een "opgepoetste" versie van Il waarin het DD- 
universum in de vorm van een DB-universum is gegoten. Het DD-universum van I2, 
dat wil zeggen de verzameling mogelijke beschrijvingen volgens I2, is een DB- 
universum DDU2 met slechts één "meta-tabelindex", de string ‘ATT’, en twee "meta- 
attributen”, de strings ‘TNAAM’ en ‘ANAAM’. De verzameling van de "object- 
tabelindexen" van het DB-universum beschreven door een element d van dom(I2) is 
{t(‘TNAAM’) | te d(‘ATT’)} en de verzameling attributen van zo’n "object- 
tabelindex" E is {x(‘ANAAM’) | x e d(‘ATT’) enx(‘TNAAM’)=E}. 

De definities van DDU2 en I2 luiden als volgt: 


DDU2 = TI({( ‘ATT’ ; P({ “‘TNAAM’ , ‘ANAAM’ } — Chs(16)))}); 
I2 = Àd e DDU?: 
II(AE e {t(‘TNAAM?’) | te d(‘ATT’)}: 
P({x(‘ANAAM’) | x e d(‘ATT’) en x(‘TNAAM’) = E} — Chs(16))) 
Het door g3 volgens I1 beschreven DB-universum uit Voorbeeld 8.1 kan ook worden 


beschreven volgens I2, en wel door de functie d1 over { ‘ATT’ } waarvoor d1(‘ATT’) 
de in Figuur 8.1 gerepresenteerde tabel over { ‘TNAAM’ , ‘ANAAM’ } is. 


d1(‘ATT?’): 


ADDRESS 
CITY 


DCODE 
DCODE 
DNAME 
MANNAME 


Figuur 8.1: Een beschrijving volgens 12 


Ter illustratie van de definitie van I2 zullen we I2(d1) even uitrekenen. Bij de bereke- 
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ning van I2(d1) maken we achtereenvolgens gebruik van de definitie van I2, tweemaal 
van de definitie van d1 en tenslotte van Lemma 0.15(a): 


I2(d1) 
=TI(E e {t(‘NAAM’) | te d1(‘ATT’)}: 

P({x(‘ANAAM’) | x e d1(‘ATT’) en x(‘TNAAM’) = E} —> Chs(16))) 
=TI(AE e { ‘EMP’, ‘DEP’}: 

P({x(‘ANAAM?) | x e d1(‘ATT’) en x(“TNAAM?) = E} —> Chs(16))) 
= TI({( ‘EMP’; P({ ‘ENAME’ , ‘ADDRESS’, ‘CITY’, ‘DCODE’ } —> Chs(16))) 
(‘DEP’; P({ ‘DNAME’, ‘DCODE’, ‘MANNAMEP’ } — Chs(16)))}) 

= TI({(‘EMP’; P(I({(‘ENAME?’ _ ; Chs(16)), 
(‘ADDRESS’ ; Chs(16)), 
(CITY? ; Chs(16)), 
(‘DCODE’?  ; Chs(16))}))), 
(“DEP’; P(II({(‘DNAME’ __ ; Chs(16)), 
(‘DCODE’ __ ; Chs(16)), 
(‘MANNAME’; Chs(16))})))}). 


’ 


We zien dus dat I2(d1) = I1(g3). 


Dat het volgens I1 beschreven DB-universum aan het eind van Voorbeeld 8.1 ook kan 
worden beschreven volgens I2 is geen toevalligheid, want I2 is DD-equivalent met I1. 
Volgens Lemma 8.1 kan dit worden bewezen door twee conversiefuncties h12 en h21 
te definiéren zodanig dat 


I1 =1I2 0 h12 en 2=I1o h21 


We definiëren hier alleen de conversiefunctie h21. De definitie van h12 en de bewijzen 
van de twee bovengenoemde eigenschappen worden in Opgave 8.3 aan de lezer over- 
gelaten. 


h21 =d e DDU2: 
NE e (t(“TNAAM’) | te d(‘ATT’)}: 
{x(‘ANAAM’) | xe d(‘ATT’) en x(‘TNAAM’)=E} 


O Voorbeeld 8.2. 
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We merken op dat de DD-functie I2 uit Voorbeeld 8.2 de interessante eigenschap heeft dat 
het DD-universum van I2 zelf een DB-universum is. De eigenschap dat het DD-universum 
dezelfde "structuur" heeft als de DB-universa, kan in de praktijk zeer nuttig zijn. Het raad- 
plegen en wijzigen van de data dictionary zou dan namelijk op dezelfde manier kunnen 
gebeuren als het raadplegen en wijzigen van de databases zelf! En aangezien het wijzigen 
van de data dictionary (alias "systeem-database") in feite neerkomt op het definiéren (of het 
herdefiniëren) van de eigenlijke database (alias "object-database"), kunnen we dus ook 
inzien dat definitie én gebruik van de database met hetzelfde mechanisme zouden kunnen 
worden gerealiseerd. (Onder gebruik verstaan we raadpleging en wijziging van de inhoud.) 


DD-functies zoals I2, waarvan het DD-universum zelf een DB-universum is, zullen we DB- 
vormig noemen: 


DEFINITIE 8.3: 
Als J een DD-functie is, dan: 
I is DB-vormig <> dom(/) is een DB-universum. 


Als J een DB-vormige DD-functie is dan noemen we het DD-universum dom(/) wel een 
meta DB-universum, een element van dom(/) wel een meta DB-toestand, de tabelindexen 
van het DB-universum dom(/) wel meta-tabelindexen en de attributen van dom(/) wel meta- 
attributen (zoals we overigens in Voorbeeld 8.2 reeds deden). 


Van een DB-vormige DD-functie / kunnen we ons afvragen of het DB-universum dom(/) 
zelf kan worden beschreven met behulp van /, met andere woorden of er een doe dom(/) 
bestaat zodanig dat /(do) = dom(/), dus kortom, of dom(/) e rng(!). In dat geval noemen we 
I zelfregistreerbaar: 


DEFINITIE 8.4: 
Als J een DD-functie is, dan: 
I is zelfregistreerbaar D dom(/) e mg(/). 


Dat elke zelfregistreerbare DD-functie DB-vormig is, volgt onmiddellijk uit bovenstaande 
definitie (en is daarom niet expliciet als voorwaarde in de definitie zelf opgenomen). 


Zelfregistreerbaarheid van een DD-functie / impliceert in feite dat de in / gebruikte struc- 
turen niet complexer zijn dan de met behulp van / te beschrijven structuren. Een van de 
interessante aspecten van zelfregistreerbare DD-functies is dat ze als het ware replica's van 
hun eigen DD-universum kunnen maken. Deze eigenschap kan zowel bij het bouwen van 


DBMS-en als voor het simuleren van de data dictionary van een gegeven DBMS zeer nuttig 
zijn. 
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VOORBEELD 8.3: 
De DD-functie I2 uit Voorbeeld 8.2 is zelfregistreerbaar. Om dit aan te tonen 


definiéren we de volgende tabelwaardige functie: 


d2 = {(‘ATT’;{ {((‘TNAAM’; ‘ATT’), (‘ANAAM’; ‘TNAAM’)}, 
{(‘TNAAM’; ‘ATT’), (‘ANAAM’; ‘ANAAM’)}})} 


Deze meta DB-toestand d2 kunnen we dus ook als volgt representeren: 


d2(‘ATT’): 


Figuur 8.2: Een beschrijving volgens 12 
Met behulp van de definities van I2 en d2 gaan we nu I2(d2) uitrekenen: 


12(d2)= T(E e (“ATT’}: P((“TNAAM’ , ‘ANAAM’ } — Chs(16))) 
= II (CATT’ ; P((“TNAAM? , ‘ANAAM’ } —> Chs(16)))} ) 
= DDU2 
= dom(1I2) 


Hiermee hebben we bewezen dat I2 inderdaad zelfregistreerbaar is. 


De DD-functie I1 uit Voorbeeld 8.1 is niet zelfregistreerbaar, want I1 is zelfs niet DB- 
vormig: 


dom(I1) = Chs(16) > P(Chs(16)) , 


dus niet alle elementen van dom(I1) hebben hetzelfde domein (wat bij een DB- 
universum wel het geval is). 


O Voorbeeld 8.3. 


We zullen nu een wat groter (en realistischer) voorbeeld van een DD-functie geven. 
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VOORBEELD 8.4: 
We zullen een (DB-vormige) DD-functie 13 definiëren waarmee DB-universa met de 
volgende mogelijkheden kunnen worden beschreven: 


(M1) 


(M2) 


(M3) 


(M4) 


(MS) 


Attributen kunnen "van type integer" of "van type string" zijn (aangegeven 
met ‘N’ respectievelijk ‘C’). 

De maximale "veldlengte" kan per attribuut worden gekozen (met een 
bovengrens van 256). We merken op dat in de voorbeelden 8.1 en 8.2 de 
maximale veldlengte in de definitie van een DB-universum niet kan worden 
gekozen, maar altijd 16 moet zijn. (Desalniettemin kunnen de actuele 
veldlengten in de tupels van een DB-toestand wel kleiner dan 16 zijn.) 

De veldlengte van een attribuut "van type integer" kan echter niet meer dan 9 
bedragen. 


Een tabel(-index) kan meerdere sleutels hebben, maar elke sleutel is enkel- 
voudig (dat wil zeggen bestaat uit precies één attribuut). 


Er kunnen verbindingseisen (van precies één attribuut naar precies één attri- 
buut) worden weergegeven; de attributen mogen hierbij in dezelfde tabel voor- 
komen. 


De definitie van DDU3, het DD-universum van 13, wordt voorafgegaan door de 
definities van twee "meta-objectkarakteriseringen", FATT3 en FREF3, een "meta- 
tupelkarakterisering" TATT3 en een "DD-karakterisering" DDK3 die aan elk van de 
twee meta-tabelindexen ‘ATT’ en ‘REF’ de verzameling toegestane "meta-tabellen" 
voor die meta-tabelindex toevoegt: 


FATT3 = {(“‘TNAME’ ; Chs(18)), 


(‘ANAMEP’ ; Chs(16)), 
(CTE SEN (M1) 
(CSE 3 ths 20, (M2) 


( ‘KEY’ : Er : 6? D] 


TATT3 = {t | te II(FATT3) en 


als t(‘TYPE’)= ‘N’ dan t(‘SIZE’)< 9}; (M3) 
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FREF3 = ((“TNAMEI’ ; Chs(18)), 
(‘ANAME]!’ ; Chs(16)), 
(‘TNAME2’ ; Chs(18)), 
(‘ANAME2’ ; Chs(16))}; 


DDK3 = {(‘ATT’ ; {T c TATT3 | { ‘TNAMB’ , ‘ANAME? } is ui. in T}), 
(‘REF’ ; P(II(FREF3)))}; 


DDU3 = {d | de TI(DDK3) en 
{(‘TNAME1’ ; ‘TNAME’), (‘ANAME1’ ; ‘ANAME?’ )} verbindt 
d(‘REF’) met d(‘ATT’) en 
{(‘TNAME2’ ; ‘TNAMB’ ), (‘ANAME2’ ; ‘ANAME?)} verbindt 
d( ‘REF’ ) met d(‘ATT’)}. 


We definiëren nu onze DD-functie I3 over DDU3 op de volgende (top-down) manier: 


I3 =d e DDU3: 
{v |v e II(DBK34) en 
Vy e d(‘REF’) : {(y(‘ANAME1’) ; y(‘ANAME2’))} verbindt (M5) 
v(y(‘TNAME1’)) met v(y(‘TNAME2’ )) }, 


waarbij we voor elke de DDU3 de databasekarakterisering DBK3, als volgt 
definiéren: 


DBK3, = 
NE e {t(“TNAME’) Ite d(‘ATT’)}: 
(T IT EII(FK4z) en 
Vx e d(‘ATT’): als x(‘KEY’)= ‘*’ enx(‘TNAME’ )=E (M4) 
dan {x(‘ANAMB’ )} is u.i. in T} , 


waarbij we voor elke de DDU3 en elke E e (t(“TNAME’) |t e d(‘ATT’)} de 
objectkarakterisering FK4 g voor E als volgt definiëren: 


FKar = 
{(¢(‘ANAMB’); Chs(¢( ‘SIZE’))) | t € d(‘ATT’) en t(“TNAME’) =E en t( TEPE je C 
{(¢(“ANAMB’ ); Int(t(‘SIZE’))) | t € d(‘ATT’) en t(‘TNAME’)=E en (CTYPE Ja N] 


Figuur 8.3 representeert een beschrijving d3 volgens I3 van een iets verfijnder DB- 
universum dan I1(g3) uit Voorbeeld 8.1 (ofwel I2(d1) uit Voorbeeld 6.2). 
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eare EEE 


ENAME 
ADDRESS 
CITY 


DCODE 
DCODE 
DNAME 
MANNAME 


d3( ‘REF’ ): 


| TNAMEL e onl ANAME? 
EMP DCODE DCODE 
MANNAME ENAME 
Figuur 8.3: Een beschrijving volgens 13 


Ter illustratie van de definities van 13, DBK34 en FKg g gaan we I3(d3) eens helemaal 
uitrekenen. We werken eerst I3 en dan d3( ‘REF’ ) uit: 


13(d3) 
= {y | ve II(DBK3,3) en 
Vy e d3(‘REF’): {(y(‘ANAME1’); y( ‘ANAME?’ ))} verbindt 
v(y(*TNAME1’)) met v(y(‘TNAME2’))} 
= {v lve II(DBK343) en 
{(‘DCODE’; ‘DCODE’ )} verbindt v( ‘EMP’ ) met v( ‘DEP’ ) en 
{(‘MANNAME’; ‘ENAME’ )} verbindt v( ‘DEP’ ) met v( ‘EMP’ )}, 


waarbij (volgens de definitie van DBK3 3 en de eigenschappen van d3( ‘ATT’ )) 
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DBK343 
=E e (t(‘NAME’) | te d3 (‘ATT’)}: 
{T | T c II(FK 3,5) en 
Vx e d3 (‘ATT’): alsx(‘KEY’) = ‘*’ enx(‘TNAME’) =E 
dan {x(‘ANAME?’)} is u.i. in T} 
=E e { ‘EMP’, ‘DEP’ }: 
{T | T c I(FKa3, g) en 
Vx e d3 (‘ATT’): als x(‘KEY’) = ‘*’ enx(‘TNAME’)=E 
dan {x( ‘ANAME’ )} is u.i. in T} 
= {(‘EMP’; {T | T c II(FK3, ‘Emp’ ) en 
{ ENAME’ } is ui. in T}), 
(‘DEP’; {T | T c II(FK3, ‘pgp’ ) en 
{ ‘DCODB’ } is u.i. in T en 
{ ‘DNAMB’ } is u.i. in T})}, 


waarbij (volgens de definitie van FKąa3,g en het gegeven dat er in d3(‘ATT’) alleen 
maar het type ‘C’ voorkomt) 


FKa3,E 
= {(t (‘ANAME’); Chs(t(‘SIZE’)) | t e d3(‘ATT’) en t(“TNAME’) = E en 
t(‘TYPE’) = ‘C’} U 
{(t(‘ANAMB’); Int(t(‘SIZE’))) | te d3(‘ATT’) en t(‘TNAMB’) = E en 
t(‘TYPE’) = ‘N’} 
= {(t(‘ANAMBE’); Chs(16)) =| te d3(‘ATT’) ent(‘TNAMB’) = E} 


zodat volgens de definitie van d3( ‘ATT’ ) 


FKas, ‘emp’ = {( ‘ENAME? _ ; Chs(16)), 
(‘ADDRESS’ ; Chs(16)), 
( ‘CITY’ ; Chs(16)), 
(‘DCODE’ ;Chs(16)} en 
FKy3, ‘pep’ = {(‘DCODE’ ;Chs(16)), 
(‘DNAMB’ __ ;Chs(16)), 
(‘MANNAMEB’; Chs(16))}. 


Hiermee hebben we het DB-universum I3(d3) helemaal uitgerekend. Na vergelijking 
met Voorbeeld 8.2 is het eenvoudig in te zien dat 13(d3) c I2(d1); immers, 
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I2(d1) = II({( ‘EMP’ ; PAIFKa, ‘gmp’ ))), 
( ‘DEP’ ; P(II(FK 3, ‘per’ )))}).- 


Het DB-universum 13(d3) is dus duidelijk een verfijning van het constraints-arme DB- 
universum I2(d1). 


I3 is een voorbeeld van een DB-vormige DD-functie want het domein van 13, DDU3, is 
een DB-universum (en wel over {(‘ATT’; dom(FATT3)), (‘REF’; dom(FREF3))}). 13 
is echter niet zelfregistreerbaar: met behulp van I3 kunnen we géén "enumeratie-typen" 
(zoals { ‘*’, ‘—’}) beschrijven, géén willekeurige "subrange-typen" (zoals [1 … 256]), 
géén tupelconstraints (zoals (M3) in de definitie van TATT3), géén samengestelde 
sleutels (zoals de sleutel {“TNAME’, ‘ANAME’} van ‘ATT’ in DDU3), en géén 
verbindingseisen met meer dan één attributenpaar (zoals die in de definitie van DDU3 
zelf tot tweemaal toe voorkomen). 


Het DB-universum SPSU uit Voorbeeld 2.17 kan niet worden beschreven volgens 13 
omdat middels 13 geen samengestelde sleutels kunnen worden weergegeven. 


De DD-functie 13 is ten minste even expressief als de DD-functie I2 uit Voorbeeld 8.2. 
Om dit te bewijzen is het volgens Lemma 8.1 voldoende om een functie h te definiëren 
zodanig dat I2 = 13 o h. De volgende conversiefunctie h23 heeft die gewenste eigen- 
schap (zie Opgave 8.5): 


h23=Ad e DDU2: 
{(‘ATT’ ; {t U t23 | te d(‘ATT’)}), 
(REF; @)} , 


waarbij t23 = {( ‘TYPE’ ; ‘C’), (‘SIZE’ ; 16), (‘KEY’ ; ‘—’)} 
Dus h23 zet elke beschrijving d volgens I2 om in de (equivalente) beschrijving volgens 


I3 waarvan de ‘REF’ -tabel leeg is en de attributen ‘TYPE’, ‘SIZE’ en ‘KEY’ in elk 
tupel van de (nieuwe) ‘ATT’ -tabel de (vaste) waarden ‘C’, 16 en ‘—’ hebben. 


O Voorbeeld 8.4. 


Het volgende voorbeeld toont aan dat er voor een element van een gegeven DD-universum 


Le "n 


soms meer dan één "natuurlijke" interpretatie mogelijk is. 
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VOORBEELD 8.5: 
We definiëren een tweede DD-functie over DDU3, het DD-universum waarover we in 
Voorbeeld 8.4 ook al de DD-functie 13 hebben gedefinieerd. Met deze nieuwe DD- 
functie kunnen DB-universa worden beschreven met nagenoeg dezelfde mogelijkheden 
als die in Voorbeeld 8.4; alleen mogelijkheid (M4) is vervangen, en wel door de vol- 
gende: 


(M4’) Elke tabelindex kan maar één sleutel hebben; deze sleutel mag echter 
samengesteld zijn. 


Dankzij het feit dat we onze definities vrij "modulair" hebben opgezet, hoeven we maar 
één nieuwe hulpdefinitie in te voeren om onze nieuwe DD-functie I4 te kunnen 
definiëren. In de hulpfunctie DBK4,, die aan elke tabelindex de verzameling van alle 
voor die tabelindex toegestane tabellen toevoegt, wordt tot uitdrukking gebracht dat 
voor elke tabelindex E de verzameling van alle attributen van E die van een ster (‘*’) 


zijn voorzien tezamen één sleutel vormen, althans, als er ten minste één "ster-attribuut" 
van E bestaat. 


De definitie van onze DD-functie 14 over DDU3 luidt nu als volgt: 


4 = 
Xd e DDU3: 
{v I v e II(DBK4,) en 
Vy e d(‘REF’): {(y(‘ANAME1’); y(‘ANAME2’ ))} verbindt (MS) 


v(y(“‘TNAME1’) met v(y(‘TNAME2’))}, 


waarbij we voor elke de DDU3 de databasekarakterisering DBK4, als volgt 
definiéren: 


DBK4, = 
NE e (t(“TNAME’)I t e d(‘ATT’)}: 
{T I T c II(FKye) en 
als (dx e d(‘ATT’):x(‘KEY’) = ‘*’ enx(‘TNAME’)= E) (M4’) 
dan (x(“ANAME’) |x e d(‘ATT’) enx(‘KEY’)= ‘*’ en 
x(‘TNAMB’) =E} is ui. inT}. 


Ter illustratie representeert Figuur 8.4 een beschrijving d4 (volgens 14) van het DB- 
universum SPSU uit Voorbeeld 2.17. We wijzen hierbij nog eens op het verschil in 
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interpretatie van de sterretjes (‘*’ ) in Voorbeeld 8.4 en die in het huidige voorbeeld. 


S# C > 
SNAME C 20 


STATUS 


d4( ‘ATT’ ): 


VVV B WU U WA 


RARA 2 


d4(“REF’): 


Figuur 8.4: Een beschrijving van SPSU volgens 14 


Omdat 14 niet meer dan één sleutel per tabelindex kan beschrijven, kan het DB- 
universum 13(d3) uit Voorbeeld 8.4 niet worden beschreven met 14. 


O Voorbeeld 8.5. 
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8.2 SAMENVATTING VAN DE VOORBEELDEN 
Ter afsluiting van dit hoofdstuk hebben we in Figuur 8.5 nog eens samengevat welke DD- 


functies welke DB-universa kunnen beschrijven en welke DD-functies DB-vormig dan wel 
zelfregistreerbaar zijn. 


11(g3) (Vb. 8.1) 
13(d3) (Vb. 8.4) 
SPSU (Vb. 8.5) 
DDU2 (Vb. 8.2) 
DDU3 (Vb. 8.4) 


DB-vormig 
zelfregistreerbaar 


Figuur 8.5: Samenvatting van de voorbeelden 


OPGAVEN 


8.1. Geef, indien mogelijk, van elk van de volgende DB-universa een beschrijving volgens 
I1, 12, 13 of 14; geef anders, indien mogelijk, met behulp van I3 of 14 een "benadering" 
van het gewenste DB-universum (in de vorm van een bij voorkeur zo klein mogelijk 
“omhullend" DB-universum). Als ook dat niet mogelijk is, geef daarvoor dan de 
reden(en) aan en probeer alsnog een “zo goed mogelijke" benadering te geven. 


(a) VBU uit Voorbeeld 1.3. 
(b) Uw VBU2 uit Opgave 1.11. 
(c) Uw VBU3 uit Opgave 1.12. 


8.2. Bewijs dat elk DB-universum dat met behulp van de DD-functie I1 uit Voorbeeld 8.1 
te beschrijven is ook “de lege toestand” bevat. 


(Dus te bewijzen dat Vg e dom(I1) : (AE e dom(g) : Ø) e I1(g).) 
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8.3. 


8.4. 


8.5. 


8.6. 


8.7. 


8.8. 
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Deze opgave heeft betrekking op Voorbeeld 8.2. 
(a) Bereken h21(d1). 

(b) Bewijs dat I2 = I1 o h21. 

(c) Definieer een functie h12 zodanig dat I1 = I2 o h12 (en bewijs deze eigenschap). 


Ga voor elke F e {I1, I2, 13, 14} het volgende na. 
(a) Iselke U e mg(F) consistent? 
(b) Iselke U e mg(F) regulier? (Hint: Vn e IN: (Chs(n) A Z)=2@.) 


Geef telkens een bewijs of een tegenvoorbeeld. 
(Zie Opgave 1.5 voor de gebruikte terminologie.) 


Bewijs dat in Voorbeeld 8.4 het volgende geldt: 
(a) Vd e DDU2: h23(d) e DDU3; 
(b) I2=I30 h23. 


Toon aan dat de DD-functie 14 uit Voorbeeld 8.5 niet injectief is, met andere woorden 
dat er DB-universa zijn die op meer dan één wijze met behulp van I4 kunnen worden 
beschreven. (Hint: let op de sleutelbeschrijvingen.) 


(a) Is de DD-functie 14 uit Voorbeeld 8.5 DB-vormig? 
(b) Is 14 zelfregistreerbaar? 
Beargumenteer uw antwoorden. 


In deze opgave vergelijken we de beschrijvingskracht van de DD-functies I3 en I4 uit 
de voorbeelden 8.4 en 8.5. 


(a) Zijn er DB-universa die zowel volgens I3 als volgens I4 kunnen worden 
beschreven? 


(b) Is I3 ten minste even expressief als 14? 


(c) Is 14 ten minste even expressief als 13? 


Geef telkens een bewijs of een geschikt tegenvoorbeeld. 
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8.9. Bewijs dat I3 o h23 = I4 o h23, waarbij h23 de in Voorbeeld 8.4 gedefinieerde conver- 
siefunctie is. 


8.10. Bewijs dat I4 uit Voorbeeld 8.5 ten minste even expressief is als I2 uit Voorbeeld 8.2. 


8.11. (a) Geef een beschrijving van DDU2 (uit Voorbeeld 8.2) volgens 14. 


(b) Is die beschrijving van DDU2 volgens I4 ook een beschrijving van DDU2 
volgens 13? 


8.12. Beargumenteer alle "plussen" en “minnen” in Figuur 8.5 met behulp van de in de stof 
en in de opgaven gegeven eigenschappen van die voorbeelden. 
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